Enterprise Patterns MOC
Enterprise Patterns MOC
Map of Content for enterprise-grade software patterns. Covers four domains: Domain-Driven Design (DDD) tactical patterns, Enterprise Integration Patterns (EIP), CQRS and Event Sourcing, and Saga patterns for distributed transaction coordination.
DDD Patterns (Phase 10)
| Pattern | Intent | When to Use |
|---|---|---|
| Value-Object | Immutable domain concept defined by attributes, not identity | Data that represents measurements, amounts, or descriptors |
| Aggregate | Consistency boundary around a cluster of domain objects | Enforcing business invariants across related entities |
| Repository | Collection-like interface for accessing domain objects | Decoupling domain logic from persistence infrastructure |
| Domain-Events | Record of something significant that happened in the domain | Cross-aggregate communication without tight coupling |
| Bounded-Context | Explicit boundary within which a domain model applies | Large systems with multiple teams or conflicting models |
| Anti-Corruption-Layer-Pattern | Translation layer preventing foreign model corruption | Integrating with legacy systems or external services |
DDD selection guide: Use DDD patterns when the domain is complex enough that a simple CRUD model leads to an anaemic domain. If your service is mostly data in/data out with no business rules, DDD adds unnecessary ceremony.
EIP Patterns (Phase 11)
| Pattern | Intent | When to Use |
|---|---|---|
| Pipes-and-Filters | Decompose processing into independent, composable stages | Multi-step message transformation or enrichment |
| Message-Router | Route messages to different destinations based on content or rules | Content-based routing, recipient lists, dynamic routing |
| Aggregator | Combine multiple related messages into a single composite message | Collecting responses from splitter or scatter-gather |
| Splitter | Break a composite message into individual messages for parallel processing | Batch processing, fan-out to specialised handlers |
| Dead-Letter-Queue | Quarantine unprocessable messages for later inspection | Any messaging system where message loss is unacceptable |
| Idempotent-Consumer | Ensure processing a message more than once has no additional effect | At-least-once delivery, saga compensation, retry scenarios |
EIP selection guide: Use EIP patterns when services communicate via asynchronous messages. If your system uses synchronous REST/gRPC exclusively, EIP patterns add message infrastructure overhead without benefit.
CQRS and Event Sourcing (Phase 12)
| Pattern | Intent | When to Use |
|---|---|---|
| CQS-Principle | Separate methods that change state from methods that read state | Any codebase — CQS is a method-level discipline, not an architecture |
| CQRS-Pattern | Separate read and write models at the service level | ~10x read/write scaling difference or genuinely complex command logic |
| Event-Sourcing-Pattern | Persist state as an append-only sequence of domain events | Audit trail, temporal queries, event-driven architecture |
| Projections | Build read-optimised views by replaying events from the event store | CQRS read side, reporting, materialised views |
CQRS/ES selection guide: CQRS and Event Sourcing are independent patterns often combined. Do NOT adopt CQRS unless you have a ~10x read/write scaling difference. Do NOT adopt Event Sourcing unless you need a complete audit trail or temporal queries.
Saga Patterns (Phase 13)
| Pattern | Intent | When to Use |
|---|---|---|
| Choreography-Saga-Pattern | Decentralised saga where services react to domain events | 2-3 service flows with no strict ordering requirement |
| Orchestration-Saga-Pattern | Centralised saga with a coordinator managing the workflow | Branching flows, strict ordering, complex rollback |
| Compensating-Transactions | Semantic undo of completed saga steps on failure | Any saga pattern where forward steps can fail |
Saga selection guide: Use saga patterns for distributed transactions across 3+ services. For 2-service flows, use simple retry-with-compensation. Choreography for simple event chains; orchestration (Temporal/Axon) for anything with branching or complex compensation.
Cross-Layer Lineage Chains
Navigable wikilink sequences showing how patterns in different domains inherit from and extend one another.
| Chain | Lineage |
|---|---|
| Event-Driven | Observer-Pattern -> Domain-Events -> Event-Sourcing-Pattern -> CQRS-Pattern -> Choreography-Saga-Pattern |
| Command/Dispatch | Command-Pattern -> CQRS-Pattern -> Orchestration-Saga-Pattern -> Message-Router |
| Encapsulation | Facade-Pattern -> Anti-Corruption-Layer-Pattern -> Strangler Fig -> API Gateway |
| Proxy/Interception | Proxy-Pattern -> Ambassador -> Sidecar -> Service Mesh |
| Strategy/Variation | Strategy-Pattern -> Feature Flags -> Canary -> Blue/Green |
| Decorator/Middleware | Decorator-Pattern -> Pipes-and-Filters -> Sidecar |
| Aggregation | Composite-Pattern -> Aggregate -> Aggregator |
| Data Access | Prototype-Pattern -> Value-Object (copy semantics) |
Note: Patterns without wikilinks (Strangler Fig, Ambassador, Sidecar, Service Mesh, Feature Flags, Canary, Blue/Green, API Gateway) are created in Phases 14-15. Links will resolve after those phases execute.
Navigation
- Parent: Design-Patterns-MOC (root MOC, created in Phase 16)
- Sibling: GoF-Patterns-MOC