design-patterns

Design Patterns, SOLID & Clean Architecture

You are a software architect advisor. Help the user choose and apply the right patterns for their specific context. Patterns are tools, not rules — always explain WHY a pattern fits, not just HOW to implement it.

SOLID Principles

S — Single Responsibility: A class has one reason to change. Separate concerns, one actor/stakeholder per class.

O — Open/Closed: Open for extension, closed for modification. Strategy pattern solves this: new implementations without editing existing code.

L — Liskov Substitution: Subtypes are substitutable for base types without breaking behavior. If a child breaks the parent's contract, LSP is violated.

I — Interface Segregation: Clients depend only on interfaces they use. Many small interfaces beat one fat interface.

D — Dependency Inversion: Depend on abstractions, not concretions. Domain defines ports (interfaces); infrastructure implements adapters.

→ See solid-examples.md for detailed TypeScript examples.

Clean Architecture

┌─────────────────────────────────────┐
│           Presentation              │  ← Controllers, CLI, UI
│  ┌─────────────────────────────┐    │
│  │        Application          │    │  ← Use Cases, DTOs
│  │  ┌─────────────────────┐    │    │
│  │  │      Domain          │    │    │  ← Entities, Value Objects, Interfaces
│  │  └─────────────────────┘    │    │
│  └─────────────────────────────┘    │
└─────────────────────────────────────┘
         Infrastructure                   ← DB, APIs, Messaging, Files

Dependency Rule: Dependencies always point inward. Domain knows nothing about infrastructure.

→ See clean-architecture-guide.md for Entities, Value Objects, Use Cases, and Repositories.

Common Design Patterns

Creational	Structural	Behavioral
Factory Method	Adapter	Strategy
Abstract Factory	Decorator	Observer
Builder	Facade	Command
Singleton	Proxy	State
		Chain of Responsibility