domain-driven-design

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Domain-Driven Design

领域驱动设计（Domain-Driven Design）

Use this skill when

适用场景

You need to model a complex business domain with explicit boundaries.
You want to decide whether full DDD is worth the added complexity.
You need to connect strategic design decisions to implementation patterns.
You are planning CQRS, event sourcing, sagas, or projections from domain needs.

你需要为具有明确边界的复杂业务领域建立模型。
你希望判断是否值得为引入完整的DDD而承担额外的复杂度。
你需要将战略设计决策与具体的实施模式关联起来。
你正基于领域需求规划CQRS、事件溯源、Saga或投影模式。

Do not use this skill when

不适用场景

The problem is simple CRUD with low business complexity.
You only need localized bug fixes.
There is no access to domain knowledge and no proxy product expert.

问题仅为低业务复杂度的简单CRUD操作。
你仅需进行局部的bug修复。
无法获取领域知识，且没有代理产品专家可咨询。

Instructions

操作指南

Run a viability check before committing to full DDD.
Produce strategic artifacts first: subdomains, bounded contexts, language glossary.
Route to specialized skills based on current task.
Define success criteria and evidence for each stage.

在决定采用完整DDD之前，先进行可行性检查。
先产出战略层面的工件：子领域、限界上下文、语言术语表。
根据当前任务，转至对应的专项技能。
为每个阶段定义成功标准及验证依据。

Viability check

可行性检查

Use full DDD only when at least two of these are true:

Business rules are complex or fast-changing.
Multiple teams are causing model collisions.
Integration contracts are unstable.
Auditability and explicit invariants are critical.

仅当满足以下至少两项条件时，才建议采用完整的DDD：

业务规则复杂或变化频繁。
多个团队协作导致模型冲突。
集成契约不稳定。
可审计性及显式不变量至关重要。

Routing map

任务路由映射

Strategic model and boundaries:
```
@ddd-strategic-design
```
Cross-context integrations and translation:
```
@ddd-context-mapping
```
Tactical code modeling:
```
@ddd-tactical-patterns
```
Read/write separation:
```
@cqrs-implementation
```

Event history as source of truth:

@event-sourcing-architect

and

@event-store-design

Long-running workflows:
```
@saga-orchestration
```
Read models:
```
@projection-patterns
```
Decision log:
```
@architecture-decision-records
```

If templates are needed, open

references/ddd-deliverables.md

战略模型与边界：
```
@ddd-strategic-design
```
跨上下文集成与转换：
```
@ddd-context-mapping
```
战术代码建模：
```
@ddd-tactical-patterns
```
读写分离：
```
@cqrs-implementation
```

以事件历史为可信源：

@event-sourcing-architect

和

@event-store-design

长运行工作流：
```
@saga-orchestration
```
读模型：
```
@projection-patterns
```
决策日志：
```
@architecture-decision-records
```

若需要模板，请打开

references/ddd-deliverables.md

。

Output requirements

输出要求

Always return:

Scope and assumptions
Current stage (strategic, tactical, or evented)
Explicit artifacts produced
Open risks and next step recommendation

需始终返回以下内容：

范围与假设
当前阶段（战略层、战术层或事件驱动层）
已产出的明确工件
未解决的风险及下一步建议

Examples

示例

text

Use @domain-driven-design to assess if this billing platform should adopt full DDD.
Then route to the right next skill and list artifacts we must produce this week.

text

使用@domain-driven-design评估该计费平台是否应采用完整的DDD，
然后转至对应的下一步专项技能，并列出我们本周必须产出的工件。

Limitations

局限性

This skill does not replace direct workshops with domain experts.
It does not provide framework-specific code generation.
It should not be used as a justification to over-engineer simple systems.

本技能无法替代与领域专家的直接研讨会。
它不提供特定框架的代码生成功能。
不应将其作为对简单系统进行过度设计的理由。