applying-design-patterns

# Applying Design Patterns ## When to use - Picking the right structure for a new feature - Refactoring duplicated logic - Need pluggable algorithms or interchangeable implementations ## Core rules 1. Use patterns by name: Factory, Repository, Strategy, Adapter, Decorator, Facade, Observer, Command, Specification 2. Patterns serve the business, not the other way around 3. Prefer composition over inheritance 4. All pattern implementations must be OOP classes with explicit typing ## Reference shape (TypeScript) ### Factory Pattern ```typescript export class UserFactory { static createRegular(id: string, email: string): User { return User.create(id, Email.create(email), ['user']); } static createAdmin(id: string, email: string): User { return User.create(id, Email.create(email), ['user', 'admin']); } } ``` ### Strategy Pattern ```typescript export interface PricingStrategy { calculate(base: number): number; } export class DiscountPricing implements PricingStrategy { constructor(private discount: number) {} calculate(base: number): number { return base - this.discount; } } ``` ### Repository Pattern ```typescript export interface OrderRepository { findById(id: string): Promise<Order | null>; save(order: Order): Promise<Order>; } ``` ## Examples — Do ```typescript // Command pattern class CreateOrderCommand { constructor(public readonly userId: string, public readonly items: OrderItem[]) {} } class CreateOrderHandler { async handle(cmd: CreateOrderCommand): Promise<Result<Order, AppError>> { ... } } ``` ## Examples — Don't ```typescript // ❌ Over-engineering: simple logic doesn't need patterns class UserBuilder { setName(n: string) { this.name = n; return this; } } ``` ## Checklist - [ ] Pattern matches the problem (Factory for creation, Strategy for algorithms) - [ ] All pattern classes are OOP with explicit types - [ ] No over-engineering simple logic See [reference/pattern-examples.md](./reference/pattern-examples.md) for full patterns.