DDD Domain Designer
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 [user] WHO [need]…UNLIKE [alternative] template. Output: vision wall.
Step 2: Scenario Analysis — Map user journeys and capture domain events (orange)/commands (blue)/roles (yellow). Output: event timeline.
Step 3: Domain Modeling — Extract entities/value objects → cluster them into aggregates → divide bounded contexts. Output: aggregate inventory.
Step 4: Microservice Decomposition — Evaluate the value of independently deploying each BC. One BC = one potential microservice. Output: context map.
Step 5: Detailed Design — Define aggregate roots, entities, value objects, domain events (past-tense naming), and invariants.
Step 6: Development and Testing — Organize development and testing around aggregates, with 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, and designing domain events and invariants.
Not for: no Event Storming input →
| basic DDD concepts →
| reviewing existing models →
| generating an API →
| simple CRUD (skip domain modeling)
Boundary
Specializes in:
- Domain model design from Event Storming results (aggregates, bounded contexts, entities/value objects)
- Applying the six aggregate design principles: consistency boundaries, small aggregates, and ID references
- Bounded context division and seven context mapping patterns
- Domain object → code object mapping (DO/DTO/VO/PO)
- Selecting value object persistence strategies (Inline/JSON/Embeddable)
- Domain event design and publication strategies, and identification of domain invariants
Requires: existing Event Storming output or clear business requirements, a selected architecture pattern, an established Ubiquitous Language (UL), and a domain expert who can review the design.
Not applicable: no Event Storming results →
| basic concepts only →
| reviewing an existing model →
| generating an API from a model →
| 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).
Target Users
| User Type | Prerequisite Knowledge |
|---|
| Backend Developer | Understands basic DDD concepts (entities/value objects/aggregates) |
| Architect | Has distributed systems experience and understands domain-driven design |
| Tech Lead | Understands DDD strategic design |
| DDD Beginner | Recommended to start with |
Event Storming-Driven Six-Step Process
See references/ddd-tactical.md and 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) Select the aggregate root → (4) Define invariants → (5) Domain expert review
Six Principles:
| # | Principle | Description | Review Focus |
|---|
| 1 | Model actual invariants within the consistency boundary | Aggregates encapsulate business rules | Could invariants be broken externally? |
| 2 | Design small aggregates | Large aggregates create concurrency bottlenecks | More than 5 entities? Any N+1 risk? |
| 3 | Reference other aggregates through unique identifiers | Between aggregates, store only IDs, not object references | Are there direct object references? |
| 4 | Use eventual consistency outside the boundary | One transaction modifies only one aggregate | Handle cross-aggregate changes asynchronously through domain events |
| 5 | Implement cross-aggregate calls through the application layer | Domain services do not directly cross aggregate boundaries | Is the application layer responsible for orchestration? |
| 6 | What fits your own context is best | Principles may be broken, but the rationale must be documented | Record the decision rationale in an ADR |
See references/advanced-tactical-patterns.md and references/domain-invariants.md
Bounded Context Division
Division Basis: Points of language change, team organizational boundaries (Conway's Law), differences in change frequency, independent deployment needs, and business capability domains (core/supporting/generic).
Seven 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 Object Types: 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 (the Repository manages DO↔PO; the Assembler converts DO→DTO; the BFF assembles DTO→VO)
See references/code-model-mapping.md
Relationship with ddd-event-storming
Recommended workflow:
(exploration) →
(detailed design) →
(implementation)
Gotchas
- Aggregate too large (10+ entities) → apply the small aggregate principle; 1–5 entities are recommended
- Missing consistency boundary (one transaction modifies two aggregate roots) → one transaction modifies only one aggregate
- Value object treated as an entity (Address has an ID) → if equality is based on attributes, it is a VO; make it immutable
- Aggregate root ID uses an auto-increment ID → use a UUID or business identifier (required for domain events/distributed unique identifiers)
- Nonstandard domain event naming → use past tense ("OrderPaid", not "PayOrder")
- Domain layer depends on framework annotations → keep the Domain layer as pure POJOs with zero framework dependencies
- Direct object reference across aggregates → hold only aggregate B's ID
- Cross-aggregate transaction → eventual consistency + Outbox Pattern
- Aggregate root behavior leaks into the Service → keep business logic cohesive in aggregate root methods; the Service only orchestrates
- Ignoring the Ubiquitous Language (UL) → keep code terminology consistent with the business language
See references/ddd-tactical.md
Validation Guide
Self-check checklist: Are invariants documented? | Does the aggregate root ID use a business identifier? | Are cross-aggregate references by ID? | Does one transaction modify one aggregate? | Are value objects immutable? | Do entities use the rich model? | Do domain events use past tense? | Does every event have a publisher/consumer? | Has a VO persistence strategy been selected? | Are BC boundaries clear? | Has the Ubiquitous Language been established? | Is the aggregate size reasonable (≤5 entities)?
FAQ
- How many entities should an aggregate contain? 1–5; if it exceeds 5, evaluate splitting it.
- Can an aggregate root be a VO? No. An aggregate root must be an entity with an independent lifecycle and globally unique ID.
- Domain service vs. application service? Domain service: business rules, such as calculating discounts. Application service: technical orchestration, such as sending a notification after creating an order.
- Is BC = microservice? Ideally, it maps to one microservice, but this can be adjusted according to team structure and deployment frequency. A BC is at least a module boundary.
- How do you distinguish an entity from a VO? Independent ID → entity. Immutable with attribute-based equality → VO. If neither applies, remodel it.
- How are cross-aggregate queries handled? The application layer composes Repository queries, or a read model/materialized view is created on the CQRS query side.
- Must a value object always be encapsulated in a class? Simple values may use primitive types; use a class when validation or behavior is needed, such as Email or Money.
- What if there is no domain expert? Identify a senior business professional or product manager to serve as the domain expert.
- Can the same entity exist in multiple BCs? Yes, but it has different meanings and attributes in each BC. For example, a "user" in the permission BC is an "account", while the same entity in the order BC is a "buyer".
- What is the Outbox Pattern? Write the domain event to the EventOutbox table in the same local transaction. A background process reads and publishes it to the MQ, ensuring at-least-once delivery.
Keywords
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
BC partitioning decision tree
References
| File | Purpose |
|---|
| references/clean-ddd-hexagonal-strategic.md | Strategic DDD design—bounded contexts, context mapping, and integration patterns |
| references/clean-ddd-hexagonal-tactical.md | Tactical DDD design—Entity/VO/Aggregate/Repository/Domain Event |
| references/ddd-tactical.md | Supplemental tactical patterns—internal aggregate construction and entity/value object code templates |
| references/code-model-mapping.md | Code model directory structure, object mapping table, and layering strategy |
| references/advanced-tactical-patterns.md | Advanced tactical patterns—Factory/Specification/Domain Service |
| references/domain-event-catalog.md | Domain event design guide—classification, data structures, and publication strategies |
| references/bounded-context-mapping.md | Detailed explanation of the seven mapping patterns—decision tree, Mermaid templates, and code examples |
| references/persistence-strategies.md | Value object persistence strategy—Inline/JSON/Embeddable decision tree |
| references/domain-invariants.md | Domain invariant design—classification, implementation patterns, specification pattern, and 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 the 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.