Architectural Patterns

Architectural patterns are reusable solutions to recurring structural problems in system design. CQRS (Command Query Responsibility Segregation) separates write models (commands) from read models (queries), enabling independent scaling and optimization of each. Event Sourcing makes the event log the primary source of truth. Hexagonal Architecture (Ports and Adapters, Alistair Cockburn) isolates the domain core from infrastructure concerns — databases, message brokers, and UIs are adapters plugged into domain-defined ports. Clean Architecture (Robert Martin) and Onion Architecture are concentric-ring variants of the same principle: dependency arrows always point inward toward the domain.

Key Points

• CQRS read models can be denormalized, pre-aggregated, and stored in whatever database is optimal for query patterns (Elasticsearch for full-text, Redis for counters, PostgreSQL for reports).
• Hexagonal Architecture defines ports as interfaces (e.g., OrderRepository, PaymentGateway) and adapters as implementations (PostgresOrderRepository, StripePaymentGateway) — swap adapters without touching domain logic.
• Clean Architecture dependency rule: source code dependencies must point inward — domain entities have zero dependencies; use cases depend on entities; interface adapters depend on use cases.
• Event Sourcing enables temporal queries: "what was the account balance on March 15?" by replaying events to that point in time — impossible with current-state-only storage.
• CQRS without event sourcing is valid and common — separate read/write data models in the same database, using materialized views or triggers to keep them in sync.
• Onion Architecture layers: Domain Model (core) → Domain Services → Application Services → Infrastructure — tests can mock any outer ring to test inner rings in isolation.
• Saga pattern (choreography or orchestration) manages distributed transactions across multiple aggregates without 2PC — each step either succeeds or triggers a compensating transaction.
• Strangler Fig Pattern: wrap legacy system with a facade, gradually extract functionality to new architecture, eventually retire the legacy system — reduces migration risk by avoiding big-bang rewrites.