architecture

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 concretions. [2][18] Fowler (2004): constructor injection is the cleanest form. [18]

// VIOLATION: class OrderService { private db = new PostgresDatabase(); }
// CORRECT:   class OrderService { constructor(private repo: OrderRepository) {} }

---

Coupling Issues [8][17]

Stevens, Myers & Constantine (1974): content coupling (direct instantiation) is the tightest and worst form. [8]

Tight Coupling [8][18]: Direct instantiation — can't mock, can't swap.

VIOLATION: class ReportGenerator { generate() { new DatabaseService().query(...) } }
CORRECT:   Inject dependencies via constructor