domain-driven-design

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Domain-Driven Design Framework

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

Framework for tackling software complexity by modeling code around the business domain. Based on a fundamental truth: the greatest risk in software is not technical failure -- it is building a model that does not reflect how the business actually works.

通过围绕业务领域建模代码来应对软件复杂度的框架。基于一个基本事实：软件最大的风险并非技术故障——而是构建的模型无法反映业务的实际运作方式。

Core Principle

核心原则

The model is the code; the code is the model. Software should embody a deep, shared understanding of the business domain. When domain experts and developers speak the same language and that language is directly expressed in the codebase, complexity becomes manageable, requirements are captured precisely, and the system evolves gracefully as the business changes.

模型即代码；代码即模型。 软件应体现对业务领域的深度共识。当领域专家与开发人员使用相同的语言，且该语言直接体现在代码库中时，复杂度将变得可控，需求得以精准捕捉，系统也能随着业务变化顺畅演进。

Scoring

评分标准

Goal: 10/10. When reviewing or creating domain models, rate them 0-10 based on adherence to the principles below. A 10/10 means full alignment with all guidelines; lower scores indicate gaps to address. Always provide the current score and specific improvements needed to reach 10/10.

目标：10/10。 在评审或创建领域模型时，根据对以下原则的遵循程度为其评分（0-10分）。10/10表示完全符合所有准则；分数越低说明存在需要改进的差距。请始终给出当前分数以及达到10/10所需的具体改进措施。

Framework

框架内容

1. Ubiquitous Language

1. Ubiquitous Language（通用语言）

Core concept: A shared, rigorous language between developers and domain experts that is used consistently in conversation, documentation, and code. When the language changes, the code changes. When the code reveals awkward naming, the language is refined.

Why it works: Ambiguity is the root cause of most modeling failures. When a developer says "order" and a domain expert means "purchase request," bugs are inevitable. A ubiquitous language forces alignment so that every class, method, and variable name maps to a concept the business recognizes and validates.

Key insights:

The language is not a glossary bolted on after the fact -- it emerges from deep collaboration
If a concept is hard to name, the model is likely wrong; naming difficulty is a design signal
Code that uses technical jargon instead of domain terms (e.g.,
```
DataProcessor
```
vs.
```
ClaimAdjudicator
```
) hides domain logic
Language must be enforced in code: class names, method names, event names, module names
Different bounded contexts may use the same word with different meanings -- and that is fine

Code applications:

Context	Pattern	Example
Class naming	Name classes after domain concepts	`LoanApplication` , not `RequestHandler`
Method naming	Use verbs the business uses	`policy.underwrite()` , not `policy.process()`
Event naming	Past-tense domain actions	`ClaimSubmitted` , not `DataSaved`
Module structure	Organize by domain concept	`shipping/` , `billing/` , not `controllers/` , `services/`
Code review	Reject technical-only names	Flag `Manager` , `Helper` , `Processor` , `Utils` as naming smells

See: references/ubiquitous-language.md

**核心概念：**Ubiquitous Language是开发人员与领域专家之间共享的严谨语言，在对话、文档和代码中保持一致使用。当语言发生变化时，代码也随之修改；当代码暴露出命名不当的问题时，语言也会得到优化。

**作用原理：**歧义是大多数建模失败的根源。当开发人员说「订单」而领域专家指的是「采购申请」时，bug将不可避免。Ubiquitous Language强制要求对齐，确保每个类、方法和变量名称都对应业务认可并验证的概念。

关键见解：

该语言并非事后添加的术语表——它源自深度协作
如果某个概念难以命名，说明模型可能存在问题；命名困难是一个设计信号
使用技术行话而非领域术语的代码（例如
```
DataProcessor
```
而非
```
ClaimAdjudicator
```
）会隐藏领域逻辑
必须在代码中强制执行该语言：类名、方法名、事件名、模块名
不同的限界上下文可能对同一词汇有不同的含义——这是正常现象

代码应用：

场景	模式	示例
类命名	以领域概念命名类	`LoanApplication` ，而非 `RequestHandler`
方法命名	使用业务领域的动词	`policy.underwrite()` ，而非 `policy.process()`
事件命名	采用过去式的领域动作	`ClaimSubmitted` ，而非 `DataSaved`
模块结构	按领域概念组织	`shipping/` 、 `billing/` ，而非 `controllers/` 、 `services/`
代码评审	拒绝仅使用技术术语的命名	将 `Manager` 、 `Helper` 、 `Processor` 、 `Utils` 标记为命名异味

参考：references/ubiquitous-language.md

2. Bounded Contexts and Context Mapping

2. Bounded Contexts（限界上下文）与上下文映射

Core concept: A bounded context is an explicit boundary within which a particular domain model is defined and applicable. The same word (e.g., "Customer") can mean different things in different contexts. Context maps define the relationships and translation strategies between bounded contexts.

Why it works: Large systems that try to maintain a single unified model inevitably collapse into inconsistency. Bounded contexts accept that different parts of the business have different models and make the boundaries explicit. Context maps then manage integration so that each context preserves its internal consistency.

Key insights:

A bounded context is not a microservice -- it is a linguistic and model boundary that may contain multiple services
Context boundaries often align with team boundaries (Conway's Law)
The nine context mapping patterns describe political and technical relationships between teams
Anti-Corruption Layer is the most important defensive pattern -- never let a foreign model leak into your core domain
Shared Kernel is dangerous: it couples two teams and should be small and explicitly governed
Start by mapping what exists (Big Ball of Mud), then define target boundaries

Code applications:

Context	Pattern	Example
Service integration	Anti-Corruption Layer	Translate external API responses into your domain objects at the boundary
Team collaboration	Shared Kernel	Two teams co-own a small `Money` value object library
Legacy migration	Conformist / ACL	Wrap legacy system behind an adapter that speaks your domain language
API design	Open Host Service + Published Language	Expose a well-documented REST API with a canonical schema
Module boundaries	Separate packages per context	`myapp.shipping` and `myapp.billing` packages with explicit translation

See: references/bounded-contexts.md

**核心概念：**限界上下文是一个明确的边界，在该边界内定义并适用特定的领域模型。同一词汇（例如「客户」）在不同上下文中可能具有不同含义。上下文映射定义了限界上下文之间的关系和转换策略。

**作用原理：**试图维护单一统一模型的大型系统最终会陷入不一致的困境。限界上下文接受业务不同部分拥有不同模型的事实，并明确划分边界。上下文映射则管理集成，确保每个上下文保持内部一致性。

关键见解：

限界上下文并非微服务——它是一个语言和模型边界，可能包含多个服务
上下文边界通常与团队边界一致（康威定律）
九种上下文映射模式描述了团队之间的政治和技术关系
防腐层（Anti-Corruption Layer）是最重要的防御模式——绝不能让外部模型渗透到你的核心领域
共享内核（Shared Kernel）存在风险：它会耦合两个团队，因此应保持规模小且受明确管控
先映射现有系统（大泥球），再定义目标边界

代码应用：

场景	模式	示例
服务集成	防腐层	在边界处将外部API响应转换为你的领域对象
团队协作	共享内核	两个团队共同维护一个小型 `Money` 值对象库
遗留系统迁移	遵循者/防腐层	用适配层包裹遗留系统，使其使用你的领域语言
API设计	开放主机服务+发布语言	暴露带有规范 schema 的文档化REST API
模块边界	按上下文拆分包	`myapp.shipping` 和 `myapp.billing` 包，带有明确的转换逻辑

参考：references/bounded-contexts.md

3. Entities, Value Objects, and Aggregates

3. 实体、值对象与聚合

Core concept: Entities have identity that persists across state changes. Value Objects are defined entirely by their attributes and are immutable. Aggregates are clusters of entities and value objects with a single root entity that enforces consistency boundaries.

Why it works: Without these distinctions, systems treat everything as a mutable, identity-bearing object with database-level relationships, leading to tangled state, inconsistent updates, and fragile concurrency. Aggregates draw a consistency boundary: everything inside is guaranteed consistent; everything outside is eventually consistent.

Key insights:

Entity: "Am I the same thing even if all my attributes change?" (a person changes name, address, job -- still the same person)
Value Object: "Am I defined only by my attributes?" (a $10 bill is interchangeable with any other $10 bill)
Most things in a domain model should be Value Objects, not Entities -- prefer immutability
Aggregate Root is the single entry point: external objects may only hold references to the root
Keep aggregates small -- one root entity plus a minimal cluster of closely related objects
Reference other aggregates by ID, not by direct object reference
Design for eventual consistency between aggregates; immediate consistency only within an aggregate

Code applications:

Context	Pattern	Example
Identity tracking	Entity with ID	`Order` identified by `orderId` , survives state changes
Immutable attributes	Value Object	`Address(street, city, zip)` -- replace, never mutate
Consistency boundary	Aggregate Root	`Order` is root; `OrderLine` items exist only through it
Cross-aggregate reference	Reference by ID	`Order` stores `customerId` , not a `Customer` object
Concurrency control	Optimistic locking on root	Version field on `Order` ; conflict if two edits race

See: references/building-blocks.md

**核心概念：**实体具有在状态变化中保持不变的标识。值对象完全由其属性定义，且不可变。聚合是实体和值对象的集群，拥有一个根实体来强制实施一致性边界。

**作用原理：**如果没有这些区分，系统会将所有事物视为带有数据库级关系的可变、带标识对象，导致状态混乱、更新不一致和并发脆弱。聚合划定了一致性边界：内部所有对象保证一致；外部对象最终一致。

关键见解：

实体：「即使所有属性都改变，我还是同一个事物吗？」（一个人改变姓名、地址、工作——仍然是同一个人）
值对象：「我仅由属性定义吗？」（一张10美元钞票与其他任何10美元钞票可互换）
领域模型中的大多数事物应该是值对象，而非实体——优先选择不可变性
聚合根是唯一的入口点：外部对象只能持有根的引用
保持聚合规模小——一个根实体加上最少的紧密相关对象集群
通过ID引用其他聚合，而非直接对象引用
为聚合之间的最终一致性设计；仅在聚合内部保证即时一致性

代码应用：

场景	模式	示例
标识跟踪	带ID的实体	`Order` 由 `orderId` 标识，状态变化后仍存在
不可变属性	值对象	`Address(street, city, zip)` ——替换，绝不修改
一致性边界	聚合根	`Order` 是根； `OrderLine` 仅通过它存在
跨聚合引用	通过ID引用	`Order` 存储 `customerId` ，而非 `Customer` 对象
并发控制	根实体的乐观锁	`Order` 上的版本字段；若两个编辑冲突则触发异常

参考：references/building-blocks.md

4. Domain Events

4. Domain Events（领域事件）

Core concept: A domain event captures something that happened in the domain that domain experts care about. Events are named in past tense (

OrderPlaced

PaymentReceived

) and represent facts that have already occurred.

Why it works: Domain events decouple the cause from the effect. When

OrderPlaced

is published, the shipping context, billing context, and notification context can each react independently without the ordering context knowing about any of them. This reduces coupling, enables eventual consistency, and creates a natural audit trail.

Key insights:

Name events in past tense: something that happened, not something that should happen
Events are immutable facts -- once published, they cannot be changed or retracted
Domain events differ from integration events: domain events are internal to a bounded context; integration events cross boundaries
Events enable temporal decoupling: the producer does not wait for the consumer
Event sourcing stores the full history of events as the source of truth, deriving current state by replaying them
Not every state change needs an event -- only publish events that the domain cares about

Code applications:

Context	Pattern	Example
State transitions	Raise event on domain action	`order.place()` raises `OrderPlaced` event
Cross-context integration	Publish integration event	`OrderPlaced` triggers `ShippingLabelRequested` in shipping context
Audit trail	Store events as history	Event log: `OrderPlaced` -> `PaymentReceived` -> `OrderShipped`
Eventual consistency	Async event handlers	`InventoryReserved` handler updates stock asynchronously after `OrderPlaced`
Event sourcing	Rebuild state from events	Replay all `Account*` events to derive current account balance

See: references/domain-events.md

**核心概念：**领域事件捕捉领域专家关心的领域内发生的事情。事件以过去式命名（

OrderPlaced

、

PaymentReceived

），代表已发生的事实。

**作用原理：**领域事件将原因与结果解耦。当

OrderPlaced

发布后，物流上下文、账单上下文和通知上下文可以各自独立响应，而无需订单上下文了解任何一个。这减少了耦合，支持最终一致性，并创建了自然的审计追踪。

关键见解：

事件以过去式命名：代表已发生的事情，而非应该发生的事情
事件是不可变的事实——一旦发布，就不能修改或撤回
领域事件与集成事件不同：领域事件在限界上下文内部；集成事件跨边界传递
事件支持时间解耦：生产者无需等待消费者
事件溯源将完整的事件历史作为事实来源，通过重放事件推导当前状态
并非所有状态变化都需要事件——仅发布领域关心的事件

代码应用：

场景	模式	示例
状态转换	领域动作触发事件	`order.place()` 触发 `OrderPlaced` 事件
跨上下文集成	发布集成事件	`OrderPlaced` 触发物流上下文中的 `ShippingLabelRequested`
审计追踪	将事件存储为历史	事件日志： `OrderPlaced` -> `PaymentReceived` -> `OrderShipped`
最终一致性	异步事件处理程序	`InventoryReserved` 处理程序在 `OrderPlaced` 后异步更新库存
事件溯源	从事件重建状态	重放所有 `Account*` 事件以推导当前账户余额

参考：references/domain-events.md

5. Repositories and Factories

5. Repositories（仓库）与Factories（工厂）

Core concept: Repositories provide the illusion of an in-memory collection of domain objects, hiding persistence details. Factories encapsulate complex object creation logic, ensuring that aggregates are always created in a valid state.

Why it works: Domain logic should never depend on how objects are stored or constructed. Repositories abstract away SQL, ORMs, and data access so that domain code reads like business logic. Factories ensure that invariants are satisfied from the moment an aggregate is born, preventing invalid objects from ever existing.

Key insights:

A Repository interface belongs in the domain layer; its implementation belongs in infrastructure
Repository methods should speak the ubiquitous language:
```
findPendingOrders()
```
, not
```
getByStatusCode(3)
```
Collection-oriented repositories mimic
```
add
```
/
```
remove
```
; persistence-oriented repositories use
```
save
```
Factories are warranted when object creation involves complex rules, conditional logic, or assembling multiple parts
Simple creation (a Value Object with two fields) does not need a factory -- a constructor suffices
The Specification pattern encapsulates query criteria as domain objects:
```
OverdueInvoiceSpecification
```

Code applications:

Context	Pattern	Example
Data access abstraction	Repository interface	`OrderRepository.findByCustomer(customerId)` in domain layer
Complex creation	Factory method	`Order.createFromQuote(quote)` validates and assembles from a `Quote` aggregate
Query encapsulation	Specification	`spec = OverdueBy(days=30); repo.findMatching(spec)`
Reconstitution	Repository loads aggregate	Repository assembles `Order` + `OrderLines` from DB rows into a complete aggregate
Ports and adapters	Interface in domain, impl in infra	`interface OrderRepository` in domain; `PostgresOrderRepository` in infrastructure

See: references/repositories-factories.md

**核心概念：**仓库提供领域对象的内存集合假象，隐藏持久化细节。工厂封装复杂的对象创建逻辑，确保聚合始终以有效状态创建。

**作用原理：**领域逻辑绝不应该依赖对象的存储或构造方式。仓库抽象了SQL、ORM和数据访问，使领域代码读起来像业务逻辑。工厂确保从聚合创建的那一刻起就满足不变量，防止无效对象的存在。

关键见解：

仓库接口属于领域层；其实现属于基础设施层
仓库方法应使用通用语言：
```
findPendingOrders()
```
，而非
```
getByStatusCode(3)
```
面向集合的仓库模拟
```
add
```
/
```
remove
```
；面向持久化的仓库使用
```
save
```
当对象创建涉及复杂规则、条件逻辑或组装多个部分时，需要使用工厂
简单创建（带有两个字段的值对象）不需要工厂——构造函数即可满足需求
规格模式（Specification pattern）将查询条件封装为领域对象：
```
OverdueInvoiceSpecification
```

代码应用：

场景	模式	示例
数据访问抽象	仓库接口	领域层中的 `OrderRepository.findByCustomer(customerId)`
复杂创建	工厂方法	`Order.createFromQuote(quote)` 验证并从 `Quote` 聚合组装
查询封装	规格	`spec = OverdueBy(days=30); repo.findMatching(spec)`
重建	仓库加载聚合	仓库从数据库行组装 `Order` + `OrderLines` 为完整聚合
端口与适配器	领域层接口，基础设施层实现	领域层中的 `interface OrderRepository` ；基础设施层中的 `PostgresOrderRepository`

参考：references/repositories-factories.md

6. Strategic Design and Distillation

6. 战略设计与领域提炼

Core concept: Not all parts of a system are equally important. Strategic design identifies the Core Domain -- the part that provides competitive advantage -- and distinguishes it from Supporting Subdomains (necessary but not differentiating) and Generic Subdomains (commodity, buy or use off-the-shelf).

Why it works: Teams that apply the same rigor to every module spread their best talent thin and over-engineer commodity functionality. By identifying the Core Domain, organizations invest their best developers, deepest modeling, and most careful design where it matters most, while using simpler approaches or third-party solutions elsewhere.

Key insights:

Core Domain: where competitive advantage lives; invest your best people and deepest modeling here
Supporting Subdomain: necessary for the business but not a differentiator; build it, but don't over-engineer
Generic Subdomain: commodity functionality (authentication, email, payments); buy or use open-source
Domain distillation extracts and highlights the Core Domain from the surrounding complexity
A Domain Vision Statement is a short document (one page) describing the Core Domain's value proposition
The Highlighted Core marks the most critical parts of the model so they receive the most attention
Revisit what is "core" as the business evolves -- today's differentiator may become tomorrow's commodity

Code applications:

Context	Pattern	Example
Build vs. buy decision	Classify subdomain type	Build custom pricing engine (core); use Stripe for payments (generic)
Team allocation	Best developers on Core Domain	Senior engineers model the underwriting rules; juniors integrate the email service
Code organization	Separate core from generic	`domain/pricing/` (deep model) vs. `infrastructure/email/` (thin adapter)
Simplification	Distill core concepts	Extract a `PolicyRatingEngine` from a monolithic `InsuranceService`
Documentation	Domain Vision Statement	One-page doc: "Our competitive advantage is real-time risk scoring using..."

See: references/strategic-design.md

**核心概念：**系统的所有部分并非同等重要。战略设计识别核心领域——提供竞争优势的部分，并将其与支撑子领域（必要但无差异化）和通用子领域（商品化，可购买或使用现成方案）区分开来。

**作用原理：**对每个模块应用相同严谨度的团队会分散最优秀的人才，并过度设计商品化功能。通过识别核心领域，组织将最优秀的开发人员、最深入的建模和最细致的设计投入到最重要的地方，而在其他地方使用更简单的方法或第三方解决方案。

关键见解：

核心领域：竞争优势所在；投入最优秀的人员和最深入的建模
支撑子领域：对业务必要但无差异化；构建它，但不要过度设计
通用子领域：商品化功能（认证、邮件、支付）；购买或使用开源方案
领域提炼从周围的复杂度中提取并突出核心领域
领域愿景声明是一份简短文档（一页），描述核心领域的价值主张
高亮核心标记模型中最关键的部分，使其获得最多关注
随着业务发展重新审视「核心」——今天的差异化因素可能成为明天的商品化功能

代码应用：

场景	模式	示例
自研vs采购决策	分类子领域类型	自研自定义定价引擎（核心）；使用Stripe处理支付（通用）
团队分配	最优秀的开发人员负责核心领域	高级工程师建模核保规则；初级工程师集成邮件服务
代码组织	核心与通用分离	`domain/pricing/` （深度模型） vs `infrastructure/email/` （轻量适配层）
简化	提炼核心概念	从单体 `InsuranceService` 中提取 `PolicyRatingEngine`
文档	领域愿景声明	一页文档：「我们的竞争优势是使用...的实时风险评分」

参考：references/strategic-design.md

Common Mistakes

常见错误

Mistake	Why It Fails	Fix
Using technical names instead of domain language	Domain logic is hidden behind `DataManager` and `ProcessorService` ; experts cannot validate the model	Rename to domain terms: `ClaimAdjudicator` , `PolicyUnderwriter` ; if no domain term exists, the concept may be wrong
One model to rule them all	A single `Customer` class serving billing, shipping, and marketing becomes bloated and contradictory	Define bounded contexts; each context gets its own `Customer` model with only the attributes it needs
Giant aggregates with many nested entities	Concurrency conflicts, slow loads, transactional bottlenecks	Keep aggregates small; reference other aggregates by ID; use eventual consistency between aggregates
Anemic domain model (all logic in services)	Domain objects are data bags; business rules scatter across service classes; duplication and inconsistency	Move behavior into entities and value objects; services only orchestrate, never contain domain logic
No Anti-Corruption Layer at integration points	Foreign models leak into your domain; your code becomes coupled to external schemas and naming	Wrap every external system behind a translation layer that converts to your ubiquitous language
Treating bounded contexts as microservices	Premature service extraction; distributed system complexity without the benefit	A bounded context is a model boundary, not a deployment unit; start with modules in a monolith
Skipping domain expert collaboration	Developers invent a model that does not match business reality; expensive rework	Regular modeling sessions with domain experts; refine the model until experts say "yes, that is how it works"

错误	失败原因	修复方案
使用技术名称而非领域语言	领域逻辑隐藏在 `DataManager` 和 `ProcessorService` 之后；专家无法验证模型	重命名为领域术语： `ClaimAdjudicator` 、 `PolicyUnderwriter` ；如果没有对应的领域术语，说明该概念可能存在问题
单一模型统管一切	服务于账单、物流和营销的单一 `Customer` 类变得臃肿且矛盾	定义限界上下文；每个上下文拥有自己的 `Customer` 模型，仅包含所需属性
包含多个嵌套实体的巨型聚合	并发冲突、加载缓慢、事务瓶颈	保持聚合规模小；通过ID引用其他聚合；接受聚合之间的最终一致性
贫血领域模型（所有逻辑在服务中）	领域对象是数据袋；业务规则分散在服务类中；重复且不一致	将行为移至实体和值对象；服务仅负责编排，绝不包含领域逻辑
集成点没有防腐层	外部模型渗透到你的领域；代码与外部 schema 和命名耦合	用转换层包裹每个外部系统，将其转换为你的通用语言
将限界上下文视为微服务	过早拆分服务；引入分布式系统复杂度却未获得相应收益	限界上下文是模型边界，而非部署单元；从单体中的模块开始
跳过与领域专家的协作	开发人员发明的模型与业务实际不符；导致昂贵的返工	定期与领域专家进行建模会话；优化模型直到专家认可「是的，这就是实际运作方式」

Quick Diagnostic

快速诊断

Question	If No	Action
Can a domain expert read your class names and understand them?	Code uses technical jargon instead of domain language	Rename classes, methods, and events to use ubiquitous language
Are bounded context boundaries explicitly defined?	Models bleed across boundaries; the same term means different things	Draw a context map; define explicit boundaries and translation strategies
Are aggregates small (one root + minimal cluster)?	Aggregates are large, slow, and have concurrency issues	Break into smaller aggregates; reference by ID; accept eventual consistency
Do domain objects contain behavior, not just data?	Anemic model; logic scattered in service classes	Move business rules into entities and value objects
Are domain events used for cross-aggregate communication?	Tight coupling between aggregates; synchronous chains	Introduce domain events; let aggregates react to events asynchronously
Is there an Anti-Corruption Layer at every external integration?	Foreign models pollute your domain	Add a translation layer at each integration boundary
Have you identified which subdomain is core?	Equal effort on everything; best talent spread thin	Classify subdomains; focus deep modeling on the Core Domain

问题	如果答案为否	行动
领域专家能否读懂你的类名并理解其含义？	代码使用技术行话而非领域语言	将类、方法和事件重命名为使用通用语言
是否明确定义了限界上下文边界？	模型跨边界渗透；同一术语含义不同	绘制上下文映射；明确定义边界和转换策略
聚合是否小巧（一个根+最小集群）？	聚合庞大、缓慢且存在并发问题	拆分为更小的聚合；通过ID引用；接受最终一致性
领域对象是否包含行为，而非仅数据？	贫血模型；逻辑分散在服务类中	将业务规则移至实体和值对象
是否使用领域事件进行跨聚合通信？	聚合之间耦合紧密；同步调用链	引入领域事件；让聚合异步响应事件
每个外部集成点是否都有防腐层？	外部模型污染你的领域	在每个集成边界添加转换层
你是否识别出哪个子领域是核心？	所有部分投入同等精力；最优秀的人才分散	分类子领域；将深度建模聚焦于核心领域

Reference Files

参考文件

ubiquitous-language.md: Building a shared language, glossary maintenance, naming in code, language evolution
bounded-contexts.md: Context boundaries, nine mapping patterns, team relationships, integration strategies
building-blocks.md: Entities, Value Objects, Aggregates, aggregate design rules, consistency boundaries
domain-events.md: Event naming, event sourcing, event-driven architecture, integration events
repositories-factories.md: Repository pattern, Factory pattern, Specification pattern, ports and adapters
strategic-design.md: Core Domain, Generic and Supporting Subdomains, distillation, build vs. buy

ubiquitous-language.md：构建共享语言、术语表维护、代码命名、语言演进
bounded-contexts.md：上下文边界、九种映射模式、团队关系、集成策略
building-blocks.md：实体、值对象、聚合、聚合设计规则、一致性边界
domain-events.md：事件命名、事件溯源、事件驱动架构、集成事件
repositories-factories.md：仓库模式、工厂模式、规格模式、端口与适配器
strategic-design.md：核心领域、通用与支撑子领域、领域提炼、自研vs采购

拓展阅读

This skill is based on the Domain-Driven Design methodology developed by Eric Evans. For the complete methodology, patterns, and deeper insights, read the original book:

"Domain-Driven Design: Tackling Complexity in the Heart of Software" by Eric Evans

本技能基于Eric Evans提出的Domain-Driven Design方法论。如需完整的方法论、模式和深入见解，请阅读原版书籍：

《Domain-Driven Design: Tackling Complexity in the Heart of Software》作者：Eric Evans

About the Author

关于作者

Eric Evans is a software design consultant and the originator of Domain-Driven Design. He has worked on large-scale systems in industries including finance, insurance, and logistics, where he developed the patterns and practices that became DDD. His 2003 book Domain-Driven Design: Tackling Complexity in the Heart of Software is widely regarded as one of the most influential software architecture books ever written. Evans founded Domain Language, a consulting firm that helps teams apply DDD to complex software projects. He is a frequent keynote speaker at software conferences worldwide and continues to refine and evolve DDD concepts through workshops, community engagement, and collaboration with practitioners. His work has shaped modern approaches to microservices, event sourcing, and strategic software design.

Eric Evans是软件设计顾问，也是Domain-Driven Design的创始人。他曾在金融、保险和物流等行业的大型系统工作，在此过程中开发了构成DDD的模式和实践。他2003年出版的《Domain-Driven Design: Tackling Complexity in the Heart of Software》被广泛认为是最具影响力的软件架构书籍之一。Evans创立了Domain Language咨询公司，帮助团队将DDD应用于复杂软件项目。他是全球软件会议的常邀主题演讲者，并通过研讨会、社区参与和与从业者的协作不断完善和演进DDD概念。他的工作塑造了微服务、事件溯源和战略软件设计的现代方法。

domain-driven-design

Original

Translation

Domain-Driven Design Framework

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

Core Principle

核心原则

Scoring

评分标准

Framework

框架内容

1. Ubiquitous Language

1. Ubiquitous Language（通用语言）

2. Bounded Contexts and Context Mapping

2. Bounded Contexts（限界上下文）与上下文映射

3. Entities, Value Objects, and Aggregates

3. 实体、值对象与聚合

4. Domain Events

4. Domain Events（领域事件）

5. Repositories and Factories

5. Repositories（仓库）与Factories（工厂）

6. Strategic Design and Distillation

6. 战略设计与领域提炼

Common Mistakes

常见错误

Quick Diagnostic

快速诊断

Reference Files

参考文件

Further Reading

拓展阅读

About the Author

关于作者