Architecture Patterns
MVC, Clean Architecture, DDD, CQRS, Event Sourcing — the shape of an entire codebase, not just one piece of it.
7.10.1Definition
Architecture patterns are high-level structural approaches for organizing an entire codebase or system — where responsibilities live, how layers communicate, how data flows — as distinct from design patterns (7.9), which solve smaller, localized problems. Common examples include MVC, Clean/Hexagonal Architecture, Domain-Driven Design, CQRS, and Event Sourcing.
7.10.2Why It Exists
Without a deliberate architectural approach, a growing codebase tends toward tangled, ad hoc structure where every part depends on every other part, making changes progressively riskier and slower. Architecture patterns exist to impose a consistent, understood shape on the system from the start, so its complexity grows in a predictable, contained way rather than accumulating as unmanaged mess.
7.10.3Pattern Overview
| Pattern | Core idea | Best fit |
|---|---|---|
| MVC | Separate data (Model), logic (Controller), and presentation (View) | Most traditional web applications |
| Clean / Hexagonal Architecture | Business logic isolated from frameworks and infrastructure | Long-lived systems needing framework independence |
| Domain-Driven Design (DDD) | Code structure mirrors real business domain concepts | Complex business logic (2.11, 2.13) |
| CQRS | Separate models for reading vs. writing data | Systems with very different read and write demands |
| Event Sourcing | State derived from a stored sequence of events, not current values alone | Systems needing a full audit history of every change |
7.10.4Common Mistakes
- Adopting a heavyweight architecture (DDD, Event Sourcing) for a simple product, imposing structural overhead the actual complexity never justifies.
- Business logic leaking into the presentation layer in an MVC app, defeating the separation of concerns the pattern was meant to enforce.
- Adopting CQRS without a genuine read/write asymmetry, doubling the model complexity for no measurable benefit.
7.10.5Best Practices
- Choose an architecture proportional to the system's actual complexity — most products are well served by straightforward MVC.
- Keep business logic isolated from framework and infrastructure code regardless of which pattern is chosen.
- Revisit architecture deliberately as complexity grows, rather than either over-architecting early or never architecting at all.