Strategic Decisions: A Framework for DDD Choices
Strategic DDD decisions shape your system's architecture for years. This chapter provides frameworks for making these decisions systematically, not ad-hoc.
TL;DR
| Decision | Key Question | Framework |
|---|---|---|
| Context boundaries | Where to draw lines? | Linguistic + team + change analysis |
| Integration pattern | How contexts communicate? | Control + model quality matrix |
| Subdomain investment | Where to focus? | Core/Supporting/Generic classification |
| Technology choices | What to use? | Fitness function evaluation |
The Strategic Decision Framework
Decision 1: Bounded Context Boundaries
The Analysis Framework
Score each potential boundary on these dimensions:
┌─────────────────────────────────────────────────────────┐
│ BOUNDARY ANALYSIS SCORECARD │
├─────────────────────────────────────────────────────────┤
│ │
│ LINGUISTIC COHESION (1-5) │
│ Do terms have consistent meaning within boundary? │
│ 5 = Perfect consistency │
│ 1 = Same words mean different things │
│ │
│ TEAM ALIGNMENT (1-5) │
│ Can one team own this boundary? │
│ 5 = Natural team ownership │
│ 1 = Multiple teams, unclear ownership │
│ │
│ CHANGE COUPLING (1-5) │
│ Do things inside change together? │
│ 5 = Changes are isolated within │
│ 1 = Changes ripple across boundaries │
│ │
│ DATA COHESION (1-5) │
│ Is data naturally grouped? │
│ 5 = Clear data ownership │
│ 1 = Data needed from many places │
│ │
│ CONSISTENCY REQUIREMENTS (1-5) │
│ Does this need strong consistency internally? │
│ 5 = Strong consistency needed │
│ 1 = Eventual consistency acceptable │
│ │
│ TOTAL: ___/25 │
│ >20 = Strong boundary │
│ 15-20 = Reasonable boundary │
│ <15 = Reconsider boundary │
│ │
└─────────────────────────────────────────────────────────┘
Example: E-Commerce Boundary Analysis
Candidate: Orders Context
| Dimension | Score | Reasoning |
|---|---|---|
| Linguistic | 5 | "Order", "Line Item", "Checkout" are clear |
| Team | 4 | Orders team owns it, some overlap with Payments |
| Change | 4 | Order logic changes independently |
| Data | 4 | Order data is self-contained |
| Consistency | 5 | Order must be consistent |
| Total | 22/25 | Strong boundary |
Candidate: "Customer" Context
| Dimension | Score | Reasoning |
|---|---|---|
| Linguistic | 2 | "Customer" means different things everywhere |
| Team | 2 | Multiple teams need customer data |
| Change | 2 | Customer changes affect many areas |
| Data | 2 | Customer data spread across systems |
| Consistency | 3 | Some consistency needed |
| Total | 11/25 | Weak boundary - split it |
Decision: Split "Customer" into Multiple Contexts
Decision 2: Integration Patterns
The Control-Quality Matrix
Choose integration pattern based on:
- Control: Do you control the upstream system?
- Model Quality: Is the upstream model good?
┌─────────────────────────────────────────────────────────┐
│ │
│ MODEL QUALITY │
│ Low High │
│ ┌───────────┬───────────┐ │
│ You │ │ │ │
│ Control │ ACL │ Customer- │ │
│ │ │ Supplier │ │
│ C ├───────────┼───────────┤ │
│ O │ │ │ │
│ N Don't │ ACL │ Conformist│ │
│ T Control │ (always) │ or │ │
│ R │ │ ACL │ │
│ O └───────────┴───────────┘ │
│ L │
│ │
└─────────────────────────────────────────────────────────┘
Decision Tree
Example Decisions
| Integration | Control | Model Quality | Pattern | Reasoning |
|---|---|---|---|---|
| Orders → Inventory | Yes | Good | Customer-Supplier | We can influence Inventory team |
| Orders → Stripe | No | Good | Conformist or ACL | Stripe's model is well-designed |
| Orders → Legacy CRM | Yes | Poor | ACL | Protect from legacy mess |
| Identity → All | Yes | Good | OHS | Many consumers |
Decision 3: Subdomain Investment
Investment Allocation Framework
┌─────────────────────────────────────────────────────────┐
│ SUBDOMAIN INVESTMENT MATRIX │
├─────────────────────────────────────────────────────────┤
│ │
│ CORE SUBDOMAIN │
│ ├── Engineering: Best engineers, dedicated team │
│ ├── Architecture: Full DDD, possibly Event Sourcing │
│ ├── Testing: Comprehensive, property-based │
│ ├── Documentation: Extensive, living docs │
│ └── Investment: 60-70% of engineering effort │
│ │
│ SUPPORTING SUBDOMAIN │
│ ├── Engineering: Competent engineers, shared team OK │
│ ├── Architecture: Simpler patterns, CRUD acceptable │
│ ├── Testing: Standard coverage │
│ ├── Documentation: Adequate │
│ └── Investment: 20-30% of engineering effort │
│ │
│ GENERIC SUBDOMAIN │
│ ├── Engineering: Any level, integration focus │
│ ├── Architecture: Use vendor's patterns │
│ ├── Testing: Integration tests only │
│ ├── Documentation: Vendor docs + integration notes │
│ └── Investment: 5-10% of engineering effort │
│ │
└─────────────────────────────────────────────────────────┘
Classification Checklist
For each subdomain, answer:
Core Indicators (3+ = Core):
- Provides competitive advantage
- Customers choose us because of this
- Requires deep domain expertise
- Changes frequently based on market
- Would be valuable to competitors
Supporting Indicators (3+ = Supporting):
- Necessary for business operations
- Similar across companies in industry
- Stable requirements
- Could describe to other companies
- No off-the-shelf solution fits perfectly
Generic Indicators (3+ = Generic):
- Same problem every company faces
- Multiple commercial solutions exist
- Well-understood, stable problem
- No competitive advantage possible
- Building custom would be wasteful
Decision 4: Technology Selection
Fitness Function Approach
Define what "good" looks like for each context:
// Example: Fitness functions for Orders Context
public class OrdersContextFitnessFunctions
{
// Performance: Order placement < 200ms p99
[Fitness("Order placement latency")]
public bool OrderPlacementLatency() =>
Metrics.GetP99("order.place.latency") < TimeSpan.FromMilliseconds(200);
// Reliability: 99.9% success rate
[Fitness("Order success rate")]
public bool OrderSuccessRate() =>
Metrics.GetSuccessRate("order.place") > 0.999;
// Consistency: No orphaned orders
[Fitness("Order consistency")]
public bool NoOrphanedOrders() =>
Database.Query<Order>(o => o.Status == "pending" && o.Age > TimeSpan.FromHours(1))
.Count() == 0;
}
Technology Decision Matrix
┌─────────────────────────────────────────────────────────┐
│ TECHNOLOGY SELECTION BY SUBDOMAIN │
├─────────────────────────────────────────────────────────┤
│ │
│ CORE SUBDOMAIN │
│ ├── Database: Depends on requirements │
│ │ • Event Sourcing? → EventStoreDB, Marten │
│ │ • Complex queries? → PostgreSQL │
│ │ • High write throughput? → Cassandra │
│ ├── Language: Team's strongest language │
│ ├── Framework: Minimal, domain-focused │
│ └── Deployment: Independent, own lifecycle │
│ │
│ SUPPORTING SUBDOMAIN │
│ ├── Database: PostgreSQL (default), or managed │
│ ├── Language: Team standard │
│ ├── Framework: Full-featured OK │
│ └── Deployment: Can share infrastructure │
│ │
│ GENERIC SUBDOMAIN │
│ ├── Database: Whatever vendor provides │
│ ├── Language: Whatever SDK is best │
│ ├── Framework: Vendor's recommended │
│ └── Deployment: SaaS when possible │
│ │
└─────────────────────────────────────────────────────────┘
Decision Documentation: ADRs
Architecture Decision Record Template
# ADR-001: Orders Context Boundary
## Status
Accepted
## Context
We need to define the boundary for order management functionality.
Currently, order-related code is spread across multiple modules.
## Decision
Create a dedicated Orders bounded context that owns:
- Order placement and modification
- Order status and lifecycle
- Order lines and pricing at time of order
The context will NOT own:
- Product catalog (Catalog context)
- Inventory levels (Inventory context)
- Payment processing (Payments context)
## Consequences
### Positive
- Clear ownership for Orders team
- Independent deployment
- Focused domain model
### Negative
- Need integration with Inventory for stock checks
- Need integration with Payments for checkout
- Some data duplication (product info at order time)
### Risks
- Over-fetching from other contexts
- Eventual consistency challenges
## Alternatives Considered
### Alternative 1: Merge with Inventory
Rejected because: Different change rates, different team expertise
### Alternative 2: Smaller boundary (just order placement)
Rejected because: Would fragment order lifecycle
Strategic Decision Checklist
Before finalizing strategic decisions:
Boundary Decisions
- Scored each boundary on 5 dimensions
- Boundaries align with team structure
- Each boundary has clear ownership
- Ubiquitous language is consistent within boundaries
- Integration points are identified
Integration Decisions
- Pattern chosen for each integration
- ACL used for external/legacy systems
- OHS defined for multi-consumer scenarios
- Contract testing planned
Investment Decisions
- Each subdomain classified (Core/Supporting/Generic)
- Core subdomains have dedicated teams
- Generic subdomains use existing solutions
- Resource allocation matches classification
Technology Decisions
- Fitness functions defined
- Technology matches subdomain type
- Team has required skills
- Migration path exists
Staff+ Interview Questions
Q: How do you make strategic DDD decisions?
A: I use a systematic framework:
- Discovery first - Event Storming, interviews, domain analysis
- Score boundaries - Linguistic, team, change, data, consistency
- Classify subdomains - Core, Supporting, Generic
- Choose integration patterns - Based on control and model quality
- Document decisions - ADRs with context and consequences
- Validate continuously - Fitness functions, retrospectives
Q: How do you handle disagreements about boundaries?
A: I facilitate data-driven discussions:
- Use the scorecard - Makes discussion concrete
- Try both - Prototype with different boundaries
- Defer to team - Who will own and maintain it?
- Accept uncertainty - Boundaries can evolve
- Document reasoning - Future team understands why
Q: What's the biggest strategic DDD mistake you've seen?
A: Treating everything as core. Teams apply full DDD with Event Sourcing to generic subdomains like authentication or email sending. This wastes engineering effort and adds unnecessary complexity. The fix: ruthlessly classify subdomains and match investment to classification.
Quick Reference Card
┌─────────────────────────────────────────────────────────┐
│ STRATEGIC DECISIONS QUICK REFERENCE │
├─────────────────────────────────────────────────────────┤
│ │
│ BOUNDARY ANALYSIS │
│ Score: Linguistic + Team + Change + Data + Consistency │
│ >20/25 = Strong boundary │
│ │
│ INTEGRATION PATTERN │
│ Control + Good Model → Customer-Supplier │
│ No Control + Good Model → Conformist │
│ Poor Model → ACL (always) │
│ Many Consumers → OHS │
│ │
│ INVESTMENT ALLOCATION │
│ Core: 60-70%, best engineers, full DDD │
│ Supporting: 20-30%, simpler patterns │
│ Generic: 5-10%, buy/outsource │
│ │
│ DOCUMENT WITH ADRs │
│ Context → Decision → Consequences → Alternatives │
│ │
└─────────────────────────────────────────────────────────┘
Next Steps
- Entities vs Value Objects - Start tactical implementation
- Aggregates - Define consistency boundaries
- Context Mapping - Implement integration patterns