Back to Details

ddd-domain-designer

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

DDD Domain Designer

DDD Domain Designer

Domain design full workflow — from event storming results to code-ready domain models, aggregates, and bounded contexts.
Domain design full workflow — from Event Storming results to code-ready domain models, aggregates, and bounded contexts.

Workflow

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: 产品愿景 — FOR [用户] WHO [需求]…UNLIKE [替代方案] 模板。产出：愿景墙。 Step 2: 场景分析 — 梳理用户旅程，捕获领域事件(橙色)/命令(蓝色)/角色(黄色)。产出：事件时间线。 Step 3: 领域建模 — 提取实体/值对象 → 聚类为聚合 → 划分限界上下文。产出：聚合清单。 Step 4: 微服务拆分 — 评估各BC独立部署价值。一个BC = 一个潜在微服务。产出：上下文映射图。 Step 5: 详细设计 — 确定聚合根、实体、值对象、领域事件(过去式命名)、不变式。 Step 6: 开发测试 — 聚合为单位组织开发测试，每聚合一个Repository接口。
详见 references/ddd-tactical.md
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

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)
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 → 
ddd-event-storming
| basic DDD concepts → 
ddd-architecture-awesome
| reviewing existing models → 
ddd-code-reviewer
| generating an API → 
ddd-api-designer
| simple CRUD (skip domain modeling)

Boundary

Boundary

擅长：
  • 从事件风暴结果到领域模型设计（聚合、限界上下文、实体/值对象）
  • 聚合设计 6 原则落地：一致性边界、小聚合、ID引用
  • 限界上下文划分和 7 种上下文映射模式
  • 领域对象→代码对象映射（DO/DTO/VO/PO）
  • 值对象持久化策略选择（Inline/JSON/Embeddable）
  • 领域事件设计与发布策略、领域不变式识别
需条件：已有事件风暴输出或明确业务需求、已选定架构模式、有统一语言(UL)、领域专家可复核。
不适用：无事件风暴结果→
ddd-event-storming
| 只需基础概念→
ddd-architecture-awesome
| 审查已有模型→
ddd-code-reviewer
| 从模型生成API→
ddd-api-designer
| 简单CRUD→跳过领域建模
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 → 
ddd-event-storming
| basic concepts only → 
ddd-architecture-awesome
| reviewing an existing model → 
ddd-code-reviewer
| generating an API from a model → 
ddd-api-designer
| simple CRUD → skip domain modeling

Audience

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).
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

用户类型前置知识
后端开发了解 DDD 基础概念（实体/值对象/聚合）
架构师有分布式系统经验，了解领域驱动设计
技术负责人理解 DDD 战略设计
DDD 初学者建议先看 
ddd-architecture-awesome
User TypePrerequisite Knowledge
Backend DeveloperUnderstands basic DDD concepts (entities/value objects/aggregates)
ArchitectHas distributed systems experience and understands domain-driven design
Tech LeadUnderstands DDD strategic design
DDD BeginnerRecommended to start with 
ddd-architecture-awesome

事件风暴驱动 6 步流程

Event Storming-Driven Six-Step Process

详见 references/ddd-tactical.md、references/clean-ddd-hexagonal-tactical.md
See references/ddd-tactical.md and references/clean-ddd-hexagonal-tactical.md

Aggregate Rules / 聚合设计五步法 + 六原则

Aggregate Rules / Five-Step Aggregate Design Method + Six Principles

五步法: (1)识别实体/值对象 → (2)一致性边界分组 → (3)选择聚合根 → (4)定义不变式 → (5)领域专家复核
六原则:
#原则说明审查要点
1一致性边界内建模真正的不变条件聚合封装业务规则不变式是否可能被外部破坏？
2设计小聚合大聚合导致并发瓶颈实体 > 5 个？有无 N+1 隐患？
3通过唯一标识引用其他聚合聚合间只记ID，不持对象引用存在直接对象引用？
4边界外使用最终一致性一个事务只改一个聚合跨聚合用领域事件异步处理
5通过应用层实现跨聚合调用领域服务不直接跨聚合应用层承担编排职责？
6适合自己才是最好的可突破原则但需记录理由ADR记录决策理由
详见 references/advanced-tactical-patterns.md、references/domain-invariants.md
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:
#PrincipleDescriptionReview Focus
1Model actual invariants within the consistency boundaryAggregates encapsulate business rulesCould invariants be broken externally?
2Design small aggregatesLarge aggregates create concurrency bottlenecksMore than 5 entities? Any N+1 risk?
3Reference other aggregates through unique identifiersBetween aggregates, store only IDs, not object referencesAre there direct object references?
4Use eventual consistency outside the boundaryOne transaction modifies only one aggregateHandle cross-aggregate changes asynchronously through domain events
5Implement cross-aggregate calls through the application layerDomain services do not directly cross aggregate boundariesIs the application layer responsible for orchestration?
6What fits your own context is bestPrinciples may be broken, but the rationale must be documentedRecord the decision rationale in an ADR
See references/advanced-tactical-patterns.md and references/domain-invariants.md

限界上下文划分

Bounded Context Division

划分依据: 语言变化点、团队组织边界(康威定律)、变更频率差异、独立部署需求、业务能力域(核心/支撑/通用)。
7种映射模式: Partnership(高耦合) | Shared Kernel(高) | Customer-Supplier(中) | Conformist(中) | Anti-Corruption Layer(低) | Open Host Service(低) | Published Language(低)
详见 references/bounded-context-mapping.md
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

四类对象: PO(持久化→Infrastructure) | DO(领域对象→Domain, 充血模型) | DTO(传输对象→Interface/App) | VO(视图对象→Interface)
转换链: VO ↔ DTO ↔ DO ↔ PO (Repository托管DO↔PO; Assembler转换DO→DTO; BFF组装DTO→VO)
详见 references/code-model-mapping.md
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

与 ddd-event-storming 的关系

Relationship with ddd-event-storming

推荐流程: 
event-storming
(探索) → 
domain-designer
(详细设计) → 
(架构Skill)
(落地实现)
Recommended workflow: 
event-storming
(exploration) → 
domain-designer
(detailed design) → 
(architecture skill)
(implementation)

Gotchas

Gotchas

  1. 聚合过大(10+实体) → 小聚合原则，推荐1-5个
  2. 缺少一致性边界(单事务改2聚合根) → 单事务只改一个聚合
  3. 值对象被当成实体(Address有ID) → 属性相等则为VO，设为不可变
  4. 聚合根ID用自增ID → 应用UUID或业务编号(领域事件/分布式唯一标识需要)
  5. 领域事件命名不规范 → 过去式("OrderPaid"非"PayOrder")
  6. 领域层依赖框架注解 → Domain层纯POJO，零框架依赖
  7. 直接对象引用跨聚合 → 只持聚合B的ID
  8. 跨聚合事务 → 最终一致性+发件箱模式(Outbox Pattern)
  9. 聚合根行为泄漏到Service → 业务逻辑内聚在聚合根方法，Service只做编排
  10. 忽略统一语言(UL) → 代码术语与业务语言保持一致
详见 references/ddd-tactical.md
  1. Aggregate too large (10+ entities) → apply the small aggregate principle; 1–5 entities are recommended
  2. Missing consistency boundary (one transaction modifies two aggregate roots) → one transaction modifies only one aggregate
  3. Value object treated as an entity (Address has an ID) → if equality is based on attributes, it is a VO; make it immutable
  4. Aggregate root ID uses an auto-increment ID → use a UUID or business identifier (required for domain events/distributed unique identifiers)
  5. Nonstandard domain event naming → use past tense ("OrderPaid", not "PayOrder")
  6. Domain layer depends on framework annotations → keep the Domain layer as pure POJOs with zero framework dependencies
  7. Direct object reference across aggregates → hold only aggregate B's ID
  8. Cross-aggregate transaction → eventual consistency + Outbox Pattern
  9. Aggregate root behavior leaks into the Service → keep business logic cohesive in aggregate root methods; the Service only orchestrates
  10. Ignoring the Ubiquitous Language (UL) → keep code terminology consistent with the business language
See references/ddd-tactical.md

验证指南

Validation Guide

自检清单: 不变式文档化? | 聚合根ID用业务标识? | 跨聚合ID引用? | 单事务改一聚合? | 值对象不可变? | 实体充血模型? | 领域事件过去式? | 每事件有发布者/消费者? | VO持久化策略选定? | BC边界明确? | 统一语言建立? | 聚合大小合理(≤5实体)?
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

FAQ

  • 聚合含多少实体？ 1-5个，超5个评估拆分。
  • 聚合根可以是VO？ 不可，聚合根必须是实体（有独立生命周期和全局唯一ID）。
  • 领域服务 vs 应用服务？ 领域服务:业务规则(如计算折扣)。应用服务:技术编排(如创建订单后通知)。
  • BC = 微服务？ 理想对应一个微服务，可根据团队/部署频率调整。BC至少是模块边界。
  • 实体 vs VO 怎么分？ 有独立ID→实体。不可变且属性相等→VO。不满足则重新建模。
  • 跨聚合查询怎么做？ 应用层组合Repository查询，或在CQRS查询侧创建读模型/物化视图。
  • 值对象一定用类封装？ 简单值可用基础类型；有验证/行为的建议类封装(Email, Money)。
  • 没有领域专家怎么办？ 从资深业务人员/产品经理中寻找担任领域专家角色。
  • 同实体可在多个BC存在？ 可以，但每个BC中有不同含义和属性(如"用户"在权限BC="账号"，在订单BC="买家")。
  • 发件箱模式(Outbox Pattern)？ 同本地事务写领域事件到EventOutbox表，后台进程读取发布到MQ，确保至少一次投递。
  • 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

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划分决策树
DDD domain design
, 
domain modeling
, 
aggregate design
, 
bounded context
, 
entity
, 
value object
, 
domain event
, 
Event Storming
, 
aggregate root
, 
consistency boundary
, 
context mapping
, 
Anti-Corruption Layer
, 
ubiquitous language
, 
code mapping
, 
DO DTO VO PO
, 
hexagonal architecture
, 
domain service
, 
aggregate anti-pattern
, 
domain invariant
, 
persistence strategy
, 
eventual consistency
, 
outbox pattern
, 
CQRS
, 
BC partitioning decision tree

References

References

FilePurpose
references/clean-ddd-hexagonal-strategic.mdDDD 战略设计—限界上下文、上下文映射、集成模式
references/clean-ddd-hexagonal-tactical.mdDDD 战术设计—Entity/VO/Aggregate/Repository/Domain Event
references/ddd-tactical.md战术模式补充—聚合内部构造、实体/值对象代码模板
references/code-model-mapping.md代码模型目录结构、对象映射表、分层策略
references/advanced-tactical-patterns.md进阶战术—Factory/Specification/Domain Service
references/domain-event-catalog.md领域事件设计指南—分类、数据结构、发布策略
references/bounded-context-mapping.md7种映射模式详解—决策树、Mermaid模板、代码示例
references/persistence-strategies.md值对象持久化策略—Inline/JSON/Embeddable决策树
references/domain-invariants.md领域不变式设计—分类、实现模式、规格模式、文档模板
references/guides/partme-13-code-model-1.md代码模型(上)—DDD微服务代码模型设计
references/guides/partme-14-code-model-2.md代码模型(下)—领域模型与代码模型一致性保证
FilePurpose
references/clean-ddd-hexagonal-strategic.mdStrategic DDD design—bounded contexts, context mapping, and integration patterns
references/clean-ddd-hexagonal-tactical.mdTactical DDD design—Entity/VO/Aggregate/Repository/Domain Event
references/ddd-tactical.mdSupplemental tactical patterns—internal aggregate construction and entity/value object code templates
references/code-model-mapping.mdCode model directory structure, object mapping table, and layering strategy
references/advanced-tactical-patterns.mdAdvanced tactical patterns—Factory/Specification/Domain Service
references/domain-event-catalog.mdDomain event design guide—classification, data structures, and publication strategies
references/bounded-context-mapping.mdDetailed explanation of the seven mapping patterns—decision tree, Mermaid templates, and code examples
references/persistence-strategies.mdValue object persistence strategy—Inline/JSON/Embeddable decision tree
references/domain-invariants.mdDomain invariant design—classification, implementation patterns, specification pattern, and documentation templates
references/guides/partme-13-code-model-1.mdCode model (Part 1)—DDD microservice code model design
references/guides/partme-14-code-model-2.mdCode model (Part 2)—ensuring consistency between the domain model and code model

Examples

Examples

FileDomain
examples/ecommerce-domain.md电商平台
examples/banking-domain.md银行系统
examples/insurance-domain.md保险业务
examples/order-fulfillment-domain.md订单履约
examples/healthcare-domain.md医疗健康
examples/payment-domain.md支付系统
examples/logistic-domain.md物流运输
FileDomain
examples/ecommerce-domain.mdE-commerce platform
examples/banking-domain.mdBanking system
examples/insurance-domain.mdInsurance business
examples/order-fulfillment-domain.mdOrder fulfillment
examples/healthcare-domain.mdHealthcare
examples/payment-domain.mdPayment system
examples/logistic-domain.mdLogistics and transportation

Security & Safety

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.
This skill is pure documentation. It does not collect user data, does not access external services or networks, and contains no executable scripts.