ddd-implement

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

One-line summary

一句话概述

Bridge a DDD pattern decision to concrete code by clarifying naming and invariants, then handing off to a language adapter skill.

通过明确命名和不变量，将 DDD 模式决策衔接到具体代码，然后移交给语言适配器 skill。

When to use this skill

何时使用此 skill

The user already knows which pattern they want (entity, value object, aggregate, domain event, repository, factory).
The target language is known (or can be inferred from the project).
The user wants idiomatic scaffolding, not just prose.

用户已经知道想要采用的模式（entity、value object、aggregate、domain event、repository、factory）。
已知目标语言，或可以根据项目推断出目标语言。
用户希望获得符合语言惯用法的代码骨架，而不只是文字说明。

When NOT to use this skill

何时不要使用此 skill

The user is still designing → route to
```
ddd-design
```
.
The user has working code with smells → route to
```
ddd-refactor
```
.
The user wants a critique of existing code → route to
```
ddd-review
```
.

用户仍在设计 → 转至
```
ddd-design
```
。
用户已有代码但存在坏味道 → 转至
```
ddd-refactor
```
。
用户希望评审现有代码 → 转至
```
ddd-review
```
。

Core content

核心内容

Three steps, in order. Do not skip step 2.

Step 1 — Confirm the pattern. Name explicitly: entity, value object, aggregate root, domain service, domain event, repository, or factory. If the user is unsure, ask — and route to the matching pattern skill for the criteria.

Step 2 — Confirm invariants and ubiquitous-language names. What must always be true? What is this thing called in the business? An entity without enforced invariants is a struct; a value object with the wrong name is a missed concept. Push back if the user offers "I'll figure that out later" — invariants belong in the constructor or factory, not in a TODO.

Step 3 — Hand off to the language adapter. Detect the target language from the project. If the project is Kotlin, route to

ddd-kotlin-idioms

. If no adapter exists for the detected language, produce pseudocode following the relevant pattern skill and note the gap so the user can author an adapter.

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

步骤 1 — 确认模式。 明确指出具体模式：entity、value object、aggregate root、domain service、domain event、repository 或 factory。如果用户不确定，则进行询问，并转至相应的模式 skill 以获取判断标准。

步骤 2 — 确认不变量与通用语言命名。 什么必须始终成立？该事物在业务中叫什么？没有强制执行不变量的 entity 只是一个 struct；命名错误的 value object 则意味着遗漏了一个重要概念。如果用户表示“我稍后再处理”，应明确指出：不变量的约束应放在构造函数或 factory 中，而不是留在 TODO 中。

步骤 3 — 移交给语言适配器。 从项目中检测目标语言。如果项目使用 Kotlin，则转至

ddd-kotlin-idioms

。如果检测到的语言没有对应的适配器，则按照相关模式 skill 生成伪代码，并说明这一空缺，以便用户自行编写适配器。

Decision heuristics

决策启发式

If invariants are unspecified, stop. Generating fields-and-getters is a disservice — it produces anemic code disguised as DDD.
Prefer immutability for value objects and identity-only equality for entities, regardless of language. Adapter skills enforce this idiomatically.
Repositories are interfaces in the domain layer; implementations live in infrastructure. The adapter places them correctly for the language's conventions.

如果未指定不变量，则停止操作。仅仅生成字段和 getter 毫无价值——这只会产出伪装成 DDD 的贫血代码。
无论采用何种语言，都应为 value object 优先使用不可变性，并为 entity 使用仅基于身份的相等性。适配器 skill 会以符合该语言习惯的方式落实这些原则。
Repository 是领域层中的 interface，具体实现位于基础设施层。适配器会按照目标语言的惯例对其进行正确放置。

Anti-patterns

反模式

Generating getters and setters with no behavior.
Producing a "DDD" entity that is really a JPA
```
@Entity
```
with annotations and nothing else.
Skipping invariant enforcement because "the application layer will validate".
Using a language's data-class equivalent for an entity (collapses identity to attribute equality).

生成没有任何行为的 getter 和 setter。
生成一个只有注解、没有任何领域逻辑的 JPA
```
@Entity
```
，并将其称为“DDD” entity。
以“应用层会进行校验”为由，跳过不变量约束。
对 entity 使用某种语言的 data class 等价形式（这会将基于身份的概念降级为基于属性相等的概念）。

References

参考资料

Evans, Domain-Driven Design (2003), Chs 5–6.

Evans，Domain-Driven Design（2003），第 5–6 章。