Domain design full workflow — from event storming results to code-ready domain models, aggregates, and bounded contexts.
Workflow
This skill covers the complete domain design pipeline from business understanding to code-ready models:
Business Requirements → [Event Storming] → 6-Step Process → Code-Ready Domain Models
Step 1: Product Vision — FOR [users] WHO [needs]…UNLIKE [alternatives] template. Output: vision wall. Step 2: Scenario Analysis — map out the user journey, capture domain events (orange)/commands (blue)/roles (yellow). Output: event timeline. Step 3: Domain Modeling — extract entities/value objects → cluster into aggregates → divide bounded contexts. Output: aggregate inventory. Step 4: Microservice Decomposition — evaluate the independent deployment value of each BC. One BC = one potential microservice. Output: context map. Step 5: Detailed Design — determine aggregate roots, entities, value objects, domain events (named in past tense), invariants. Step 6: Development and Testing — organize development and testing around aggregates as the unit, one Repository interface per aggregate.
See references/ddd-tactical.md
When to Use
Use when: designing domain models from event storming outputs, identifying aggregates/bounded contexts, mapping DO/DTO/VO/PO, selecting value object persistence strategies, designing domain events and invariants.
Not for: no event storming input → ddd-event-storming | basic DDD concepts → ddd-architecture-awesome | review existing models → ddd-code-reviewer | generate API → ddd-api-designer | simple CRUD (skip domain modeling)
Boundary
Good at：
- From event storming results to domain model design (aggregates, bounded contexts, entities/value objects)
- Implementation of the 6 aggregate design principles: consistency boundaries, small aggregates, ID references
- Bounded context division and the 7 context mapping patterns
- Domain object→code object mapping (DO/DTO/VO/PO)
- Value object persistence strategy selection (Inline/JSON/Embeddable)
- Domain event design and publishing strategy, domain invariant identification
Requires conditions: Existing event storming output or clear business requirements, an architecture pattern already selected, a ubiquitous language (UL), and domain experts available for review.
Not applicable: No event storming results→ddd-event-storming | Only need basic concepts→ddd-architecture-awesome | Review an existing model→ddd-code-reviewer | Generate API from the model→ddd-api-designer | Simple CRUD→skip domain modeling
Audience
This skill is designed for: Backend developers (implementing DDD architectures), Software architects (evaluating and selecting patterns), Tech leads (reviewing team implementations), and DDD beginners (learning domain-driven design fundamentals).
Applicable users
| User type | Prerequisite knowledge |
|---|---|
| Backend developer | Understands basic DDD concepts (entity/value object/aggregate) |
| Architect | Has distributed systems experience, understands domain-driven design |
| Technical lead | Understands DDD strategic design |
| DDD beginner | Recommended to first see ddd-architecture-awesome |
Event storming-driven 6-step process
See references/ddd-tactical.md、references/clean-ddd-hexagonal-tactical.md
Aggregate Rules / five-step aggregate design method + six principles
Five-step method: (1) identify entities/value objects → (2) group by consistency boundary → (3) choose aggregate root → (4) define invariants → (5) domain expert review
Six principles:
| # | Principle | Description | Review point |
|---|---|---|---|
| 1 | Model the true invariants within the consistency boundary | The aggregate encapsulates business rules | Could the invariant be broken externally? |
| 2 | Design small aggregates | Large aggregates cause concurrency bottlenecks | More than 5 entities? Any N+1 risk? |
| 3 | Reference other aggregates by unique identifier | Between aggregates, store only IDs, do not hold object references | Are there direct object references? |
| 4 | Use eventual consistency outside the boundary | One transaction modifies only one aggregate | Handle cross-aggregate cases asynchronously via domain events |
| 5 | Implement cross-aggregate calls through the application layer | Domain services do not cross aggregates directly | Does the application layer take on the orchestration responsibility? |
| 6 | What suits you best is the best | Principles may be broken but the reason must be recorded | ADR records the decision rationale |
See references/advanced-tactical-patterns.md、references/domain-invariants.md
Bounded Context partitioning
Basis for partitioning: language change points, team organization boundaries (Conway's Law), differences in change frequency, independent deployment needs, business capability domains (core/supporting/generic).
7 mapping patterns: Partnership (high coupling) | Shared Kernel (high) | Customer-Supplier (medium) | Conformist (medium) | Anti-Corruption Layer (low) | Open Host Service (low) | Published Language (low)
See references/bounded-context-mapping.md
Domain object → code object mapping
Four types of objects: PO (persistence → Infrastructure) | DO (domain object → Domain, rich model) | DTO (data transfer object → Interface/App) | VO (view object → Interface)
Conversion chain: VO ↔ DTO ↔ DO ↔ PO (Repository manages DO↔PO; Assembler converts DO→DTO; BFF assembles DTO→VO)
See references/code-model-mapping.md
Relationship with ddd-event-storming
Recommended process: event-storming(exploration) → domain-designer(detailed design) → (架构Skill)(implementation)
Gotchas
- Aggregate too large(10+ entities) → small aggregate principle, 1-5 recommended
- Lack of consistency boundary(modifying 2 aggregate roots in a single transaction) → modify only one aggregate per transaction
- Value object treated as entity(Address has an ID) → if attributes are equal it is a VO, make it immutable
- Aggregate root ID uses auto-increment ID → use UUID or business number (required for domain events/distributed unique identification)
- Domain event naming is non-standard → past tense ("OrderPaid" not "PayOrder")
- Domain layer depends on framework annotations → Domain layer is pure POJO with zero framework dependencies
- Direct object reference across aggregates → hold only the ID of aggregate B
- Cross-aggregate transaction → eventual consistency + Outbox Pattern
- Aggregate root behavior leaks into Service → business logic is cohesive within aggregate root methods, Service only does orchestration
- Ignoring the Ubiquitous Language (UL) → code terminology stays consistent with business language
See references/ddd-tactical.md
Validation guide
Self-check list: Are invariants documented? | Does the aggregate root ID use a business identifier? | Cross-aggregate ID references? | One aggregate modified per transaction? | Are value objects immutable? | Rich entity model? | Domain events in past tense? | Does every event have a publisher/consumer? | Is the VO persistence strategy chosen? | Are BC boundaries clear? | Is the Ubiquitous Language established? | Is the aggregate size reasonable (≤5 entities)?
FAQ
- How many entities should an aggregate contain? 1-5; evaluate splitting if more than 5.
- Can an aggregate root be a VO? No, an aggregate root must be an entity (with an independent lifecycle and a globally unique ID).
- Domain service vs. application service? Domain service: business rules (e.g., calculating discounts). Application service: technical orchestration (e.g., notifying after creating an order).
- BC = microservice? Ideally corresponds to one microservice, and can be adjusted based on team/deployment frequency. A BC is at least a module boundary.
- How to distinguish an entity from a VO? Has an independent ID → entity. Immutable and equal by attributes → VO. If neither holds, remodel.
- How to do cross-aggregate queries? Combine Repository queries at the application layer, or create a read model/materialized view on the CQRS query side.
- Must value objects always be encapsulated with classes? Simple values can use primitive types; for those with validation/behavior, class encapsulation is recommended (Email, Money).
- What if there is no domain expert? Look for senior business personnel/product managers to take on the domain expert role.
- Can the same entity exist in multiple BCs? Yes, but it has different meanings and attributes in each BC (e.g., "User" is "Account" in the authorization BC and "Buyer" in the order BC).
- Outbox Pattern? Within the same local transaction, write domain events to the EventOutbox table; a background process reads and publishes them to the MQ, ensuring at-least-once delivery.
Keywords
DDD domain design, 领域建模, aggregate design, 聚合设计, bounded context, 限界上下文, entity, value object, 值对象, domain event, 领域事件, event storming, aggregate root, 聚合根, consistency boundary, 一致性边界, context mapping, 上下文映射, Anti-Corruption Layer, 防腐层, ubiquitous language, 代码映射, DO DTO VO PO, 六边形架构, 领域服务, 聚合反模式, 领域不变式, 持久化策略, 最终一致性, outbox pattern, CQRS, BC划分决策树
References
| File | Purpose |
|---|---|
| references/clean-ddd-hexagonal-strategic.md | DDD Strategic Design—Bounded Contexts, Context Mapping, Integration Patterns |
| references/clean-ddd-hexagonal-tactical.md | DDD Tactical Design—Entity/VO/Aggregate/Repository/Domain Event |
| references/ddd-tactical.md | Tactical Pattern Supplement—Aggregate Internal Construction, Entity/Value Object Code Templates |
| references/code-model-mapping.md | Code Model Directory Structure, Object Mapping Table, Layering Strategy |
| references/advanced-tactical-patterns.md | Advanced Tactics—Factory/Specification/Domain Service |
| references/domain-event-catalog.md | Domain Event Design Guide—Classification, Data Structures, Publishing Strategies |
| references/bounded-context-mapping.md | Detailed Explanation of 7 Mapping Patterns—Decision Tree, Mermaid Templates, Code Examples |
| references/persistence-strategies.md | Value Object Persistence Strategies—Inline/JSON/Embeddable Decision Tree |
| references/domain-invariants.md | Domain Invariant Design—Classification, Implementation Patterns, Specification Pattern, Documentation Templates |
| references/guides/partme-13-code-model-1.md | Code Model (Part 1)—DDD Microservice Code Model Design |
| references/guides/partme-14-code-model-2.md | Code Model (Part 2)—Ensuring Consistency Between Domain Model and Code Model |
Examples
| File | Domain |
|---|---|
| examples/ecommerce-domain.md | E-commerce Platform |
| examples/banking-domain.md | Banking System |
| examples/insurance-domain.md | Insurance Business |
| examples/order-fulfillment-domain.md | Order Fulfillment |
| examples/healthcare-domain.md | Healthcare |
| examples/payment-domain.md | Payment System |
| examples/logistic-domain.md | Logistics and Transportation |
Security & Safety
This skill is pure documentation. It does not collect user data, does not access external services or networks, and contains no executable scripts.