语言能预测行为
- 名词对应稳定概念，而非数据库表。
- 动词表达业务动作，而非 CRUD。
- 状态变化有明确的允许条件。
- 异常是业务事实，不是笼统失败。
01 / STRATEGIC DESIGN
先理解业务，
再让 AI 写代码
DDD 不是目录结构，而是一套持续发现边界、约束与语言的协作方法。AI 可以加速提问、归纳与反例生成，但业务事实仍要由团队确认。
START HERE
模型不是现实，
而是为决策服务的
业务解释。
- 01找变化哪些规则经常独立变化？
- 02找语言同一个词是否有不同含义？
- 03找约束哪些条件必须同时成立？
- 04再建模让边界承载业务能力。
INTERACTIVE CASE / 履约域
从事件流发现边界
交易上下文
→
库存上下文
→
履约上下文
AI'S ROLE / NOT AUTOPILOT
AI 的正确位置
01扩大探索面
生成追问、异常场景和反例，帮助团队更快暴露隐含规则。
02压缩表达成本
整理访谈记录、候选术语和上下文关系，但不替代业务确认。
03持续审查漂移
对照通用语言检查代码、文档与事件命名是否逐渐分叉。
8 STOPS / 4.5 HOURS
从业务问题到可演进模型
02 / UBIQUITOUS LANGUAGE
先让词语只有
一种业务含义
通用语言不是术语表，而是业务专家与开发者在对话、文档、代码和事件中共同使用且持续校正的语言。
原始说法领域表达为什么更准确
让 AI 找歧义
你是领域语言审查员。
请对每个术语追问：
1. 谁在什么场景使用它？
2. 是否在不同流程中含义不同？
3. 它能否预测允许与禁止的行为？
4. 给出三个容易误解的反例。关键判断
当同一个词在两个团队中需要不同定义时，优先怀疑上下文边界，而不是强迫全公司共享一个大模型。
03 / BOUNDED CONTEXT
让模型在边界内
保持一致
限界上下文定义了一套模型和语言的适用范围。边界之外可以有同名概念，但必须通过显式契约协作。
销售单
承诺买卖关系、价格与支付结果。
- 成交金额
- 买家
- 支付状态
库存预留
承诺在指定仓库保留可售数量。
- SKU
- 仓库
- 预留量
履约单
承诺按地址与时效完成交付。
- 包裹
- 收件地址
- 承运商
01语言分叉
同名词开始承载不同规则。
02变化节奏不同
需求总是以不同原因修改。
03一致性要求不同
事务与可用性权衡不同。
04团队认知独立
知识与决策集中在不同团队。
BOUNDARY CHECK
“订单”应该全系统共享一个模型吗？
交易关心成交承诺，履约关心交付任务，两者变化原因不同。
选择一个答案
04 / CONTEXT MAPPING
先说清关系，
再选择集成方式
上下文地图记录团队和模型之间的关系。技术协议只是结果，真正要明确的是谁影响谁、谁负责翻译、谁承担变化成本。
UPSTREAM LANGUAGE IS UNSTABLE
防腐层 / ACL
下游不直接接受外部模型，在自己的边界创建翻译层，保护本地通用语言与业务规则。
外部支付→Translator→退款上下文
情境关系策略
关键代价
外部模型复杂且频繁变化防腐层
增加翻译代码，换取本地模型稳定。
下游能影响上游优先级客户/供应商
需要明确协作机制与验收契约。
成熟标准且差异价值很低遵奉者
主动接受上游语言，减少重复建模。
一对多提供稳定能力开放主机服务
版本治理与兼容承诺成为核心成本。
05 / TACTICAL MODELING
用对象表达约束，
不是映射数据表
战术模式服务于清晰的领域模型。先问对象如何保持合法，再决定它是实体、值对象、领域服务还是仓储。
实体
由身份延续生命周期履约单即使地址或状态改变，仍是同一张履约单。
值对象
由完整属性定义相等性金额、地址、时间窗口适合不可变并在构造时校验。
领域服务
行为不自然属于单一对象跨规则计算，但不承载流程编排和基础设施细节。
仓储
以聚合为单位恢复与保存接口表达领域需要，不暴露 ORM 查询能力。
MODEL CHECK
收件地址更适合哪种模型？
地址由省市区、街道、联系人和电话共同定义，修改后通常视为一个新值。
选择一个答案
常见误区
贫血模型把所有规则放进 Service，让实体退化为可任意修改的数据袋。能由对象自身维护的不变量，应由对象的方法保护。
06 / AGGREGATES & CONSISTENCY
围绕不变量，
决定事务边界
聚合不是对象图的容器，而是一个必须在单次事务中保持一致的边界。聚合外只通过根实体 ID引用。
FULFILLMENT AGGREGATE
ROOTFulfillmentOrder控制状态迁移与包裹创建
Parcel包裹
DeliveryWindow配送时窗
EXTERNAL IDSalesOrderID不直接持有交易聚合对象
INVARIANT CHECK
哪些规则需要同一事务？
请选择必须由履约聚合立即保护的规则。
同一聚合强一致
→业务不变量必须立即成立
跨聚合最终一致
→通过领域事件推进状态
跨上下文契约协作
超时、幂等、补偿与可观测
尺寸原则
优先设计小聚合。只有当并发冲突所保护的业务损失大于可用性代价时，才扩大强一致边界。
07 / DOMAIN EVENTS
用已经发生的事实
连接业务过程
领域事件使用过去时，记录业务上值得关注的事实。它先属于领域语言，再决定是否需要发布为集成事件。
10:02:11OrderPaid
交易上下文确认支付完成
10:02:12StockReserved
库存上下文完成预留
10:02:14FulfillmentCreated
履约上下文接受交付责任
18:20:03ParcelShipped
包裹交给承运商
领域内事实
表达本上下文中的业务含义，可包含领域对象和值对象，由聚合在事务内产生。
ParcelShipped(parcelID, carrier, occurredAt)边界外契约
面向消费者的稳定消息，字段最小、可版本化，不泄露内部对象结构。
fulfillment.parcel-shipped.v1EVENT NAMING
哪个名称最像领域事件？
事件描述已发生且业务人员能理解的事实。
选择一个答案
可靠发布
数据库提交与消息发送之间存在双写窗口。使用 Transactional Outbox + 幂等消费者，并为失败、重试和积压建立可观测性。
08 / AI MODELING WORKBENCH
让 AI 追问模型，
而不是替你拍板
高质量 AI 协作需要给出业务场景、已知事实、未知假设和输出约束。把模型建议视为待验证的候选项。
请先描述业务事实，再点击“生成建模提示词”。
DOMAIN CHECK
模型的价值，在于支持下一次正确决策
完成四项 AI 协作护栏后结束本章。把真实访谈记录、事件风暴结果和线上异常带回来，模型才会持续变得有用。