Creational Patterns - deal with object construction and referencing
Structural Patterns - deal with relationships between objects and how they interact with each other to form larger complex objects
Behavioral Patterns - deal with communication between objects especially in terms of responsibility and algorithms

top-level abstractions
shared vocabulary enables expression of intent when problem solving at the design stage
built around solid OO-design principles promoting good OO-design
describe solutions to complex problems without a need for low-level implementation details
absolute requirement for designing and creating a service-oriented architecture

promotes reusability, no need to constantly reinvent the wheel
name of design pattern reflects behavior and purpose
help to simplify complex problems "unique" problems can be solved by breaking problem down to root elements

have to fully understand problem and generalize it before applying design patterns
can make simple problems complex
design patterns are abstractions of the solution not a solution themselves

KISS - Keep It Simple Stupid - avoid unnecessary complexity, keep code simple not simplistic
DRY - Don't Repeat Yourself - avoid repetition by abstracting commonalities, applies to code and logic
Tell, Don't Ask - tell objects what actions to perform, no questions about functionality or state, helps to align responsibilities and avoid tight coupling
YAGN - You Ain't Gonna Need It - only include necessary functionality, TDD uses tests to prove functionality of a system then code is written to pass tests
SoC - Separation of Concerns - encapsulate unique behaviors and responsibilities, significantly increases code reuse, maintainability and testability

SRP - Single Responsibility Principle - close alignment with SoC, concise objects, avoid Swiss Army knife
OCP - Open-Closed Principle - types should be open for extension and closed for modification
LSP - Liskov Substitution Principle - derived class should behave the same as the parent, aligned with OCP,
ISP - Interface Segregation Principle - splitting methods of a contract into groups of responsibilities and assigning Interfaces to those groups, avoid monolythic Interfaces
DIP - Dependency Inversion Principle - isolate classes from concrete implementations, dependency should be upon Interfaces or abtract classes
DI - Dependency Injection - supply low level or dependent class via constructor, method or property, invert dependent classes to Interfaces or abstract classes, leads to loosely coupled systems that are highly testable and easy to change
IoC - Inversion of Control - flow control is inverted compared to procedural programming, IoC container injects services into client code w/o client knowing about concrete implementations

Domain Logic Patterns Object Relational Mapping web presentation patterns base, behavioral & structural patterns other design practices