architecturelisted

# Architecture Patterns Domain expertise for software architecture and design pattern analysis. Full bibliography: `references/sources.md`. ## Iron Law > **SEPARATION OF CONCERNS IS NON-NEGOTIABLE** [1][2] > > Every module has one reason to change. Every layer has clear boundaries. Every dependency > points in one direction. Parnas (1972): decompose by information hiding, not by task. > Violations compound into unmaintainable systems. [1][19] --- ## SOLID Violations [2] **SRP** — One class, one reason to change. [1][2][8] ``` VIOLATION: UserController handles HTTP + validation + DB + email CORRECT: Inject UserService, UserValidator — each class has one reason to change ``` **OCP** — Extend without modifying. [2] ``` VIOLATION: if (type === 'credit') ... else if (type === 'paypal') ... CORRECT: Strategy pattern — new payment = new class, existing code unchanged ``` **LSP** — Subtypes must be substitutable. [3] Liskov & Wing (1994): subtype cannot strengthen preconditions. Throwing where parent doesn't throw is a violation. ``` VIOLATION: ReadOnlyStorage extends FileStorage { write() { throw new Error(...) } } CORRECT: Segregated interfaces (Readable, Writable) — compile-time, not runtime ``` **ISP** — No forced unused implementations. [2] ``` VIOLATION: interface Worker { work(); eat(); sleep(); } // Robot forced to implement eat() CORRECT: interface Workable { work(): void; } — implement only what you support ``` **DIP** — Depend on abstractions, not concr