revfactory DDD Context Mapping — Domain-Driven Design Context Mapping Guide
Systematic methodology from bounded context identification to context map creation.
Event Storming Procedure
Phase 1: Domain Event Collection
Rule: Express in past tense verbs
Examples: "Order was created", "Payment was approved", "Shipping was initiated"
Collection order:
1. List events from core business flows in chronological order
2. Add exception/failure events
3. Add external system events
Phase 2: Command -> Event Mapping
[User/System] -> {Command} -> [Aggregate] -> <<Domain Event>>
[Customer] -> {Create Order} -> [Order] -> <<Order was created>>
[Payment System] -> {Approve Payment} -> [Payment] -> <<Payment was approved>>
Phase 3: Aggregate Identification
Aggregate boundary criteria:
1. Transactional consistency boundary — groups of objects that must change together
2. Invariant protection — units that enforce business rules
3. Concurrency boundary — units that manage conflicts during concurrent access
Phase 4: Bounded Context Derivation
| Signal | Meaning |
|---|---|
| Same word with different meanings | Context separation needed (e.g., "Account" = user account vs. financial account) |
| Owned by different teams | Organizational boundary = context boundary |
| Different change cadences | Independent deployment needed -> separate |
| Different data stores | Technical boundary = context boundary |
Context Map Relationship Types
| Relationship | Symbol | Description | Example |
|---|---|---|---|
| Shared Kernel | SK | Shared domain model | Two teams using the same Entity |
| Customer-Supplier | C/S | Upstream/downstream relationship | Order (upstream) -> Shipping (downstream) |
| Conformist | CF | Downstream accepts upstream model as-is | Accepting external API model |
| Anti-Corruption Layer | ACL | Insert model translation layer | Integration with legacy system |
| Open Host Service | OHS | Provide public protocol | Public REST API |
| Published Language | PL | Shared language (schema) | Protobuf/Avro schema |
| Separate Ways | SW | Independent operation | Integration unnecessary |
| Partnership | P | Equal collaboration | Joint development by two teams |
Context Map Example:
+---------------+ OHS/PL +-----------------+
| Order Mgmt | ---------------> | Payment Process |
| (Order BC) | | (Payment BC) |
+-------+-------+ +--------+--------+
| C/S | C/S
v v
+---------------+ ACL +-----------------+
| Shipping Mgmt | <--------------- | External PG |
| (Shipping BC) | | (3rd Party) |
+---------------+ +-----------------+
Aggregate Design Principles
Sizing Criteria
Prefer small aggregates:
+-- Minimize transaction scope -> reduce concurrency conflicts
+-- Reduce memory usage
+-- Shrink change impact scope
Exceptions (larger aggregates allowed):
+-- Invariants span multiple entities
+-- Atomic consistency is absolutely required
+-- Cannot be replaced with eventual consistency
Inter-aggregate Reference Rules
OK - ID reference: Order.customerId (only holds the Customer aggregate's ID)
NO - Direct reference: Order.customer (directly holds the Customer object)
Reasons:
1. Respects aggregate boundaries
2. Transaction isolation
3. Enables independent storage usage
Ubiquitous Language Dictionary Template
| Term | Context | Definition | Synonyms | Confusion/Antonyms |
|------|---------|-----------|----------|-------------------|
| Order | Order Management | Customer's product purchase request | Purchase order | Distinct from Cart |
| Account | User Management | Loginable user unit | User | Distinct from financial account |
| Account | Settlement Management | Settlement target financial account | Bank account | Distinct from user account |
Service Decomposition Anti-patterns
| Anti-pattern | Symptoms | Resolution |
|---|---|---|
| Nanoservice | Service is too small, only 1-2 APIs | Merge related services |
| Distributed Monolith | All services in synchronous call chains | Switch to event-driven async |
| CRUD Service | Acts as DB proxy without domain logic | Internalize domain logic |
| God Service | Excessive responsibilities in one service | Re-decompose based on bounded contexts |
| Shared DB | Multiple services using the same tables | Separate data ownership |