ddd-implement

一句话概述

通过明确命名和不变量，将 DDD 模式决策转化为具体代码，然后交由语言适配器技能处理。

何时使用此技能

• 用户已经知道想使用哪种模式（实体、值对象、聚合、领域事件、仓储、工厂）。
• 已知目标语言（或可从项目中推断）。
• 用户想要符合惯例的脚手架，而不只是文字说明。

何时不要使用此技能

• 用户仍在设计 → 转交给 ddd-design。
• 用户有可运行的代码，但代码存在异味 → 转交给 ddd-refactor。
• 用户想要评审现有代码 → 转交给 ddd-review。

核心内容

按顺序执行以下三个步骤。不要跳过第 2 步。

步骤 1 — 确认模式。 明确指出模式：实体、值对象、聚合根、领域服务、领域事件、仓储或工厂。如果用户不确定，请提问，并根据判断标准转交给对应的模式技能。

步骤 2 — 确认不变量和通用语言中的名称。 哪些条件必须始终成立？在业务中，这个概念叫什么？没有强制执行不变量的实体只是一个结构体；名称不当的值对象则意味着遗漏了一个概念。如果用户说“以后再说”，请提出异议——不变量应在构造函数或工厂中定义，而不是留在 TODO 中。

步骤 3 — 转交给语言适配器。 从项目中识别目标语言。如果项目使用 Kotlin，则转交给 ddd-kotlin-idioms。如果检测到的语言没有对应的适配器，请按照相关模式技能生成伪代码，并指出这一缺口，方便用户编写适配器。

判断启发

• 如果未指定不变量，请停止。生成只有字段和 getter 的代码无济于事——这会产出伪装成 DDD 的贫血代码。
• 值对象优先采用不可变性，实体优先采用仅基于身份的相等性，不论使用何种语言。适配器技能会以符合语言惯例的方式实现这些约定。
• 仓储在领域层中是接口；实现位于基础设施层。适配器会按照该语言的惯例将它们放在正确的位置。

反模式

• 生成没有任何行为的 getter 和 setter。
• 生成一个“DDD”实体，但它实际上只是带有注解、除此之外别无内容的 JPA @Entity。
• 因为“应用层会验证”而跳过不变量强制执行。
• 使用某种语言中等价于数据类的结构来表示实体（这会将身份相等性简化为属性相等性）。

另请参阅

• ddd-entity、ddd-value-object、ddd-aggregate、ddd-domain-event、ddd-repository、ddd-factory — 此技能所实现的模式基础。
• ddd-kotlin-idioms — 用于生成代码的 Kotlin 适配器。

参考资料

• Evans，领域驱动设计（2003），第 5–6 章。