# 常见误区分析

URL: https://caijiao.org/ddd/chapter8/pitfalls
Source: docs/ddd/chapter8/pitfalls.md
Description: 分析在领域驱动设计（DDD）实践中容易陷入的常见误区，帮助开发者更好地理解和应用 DDD。

领域驱动设计（DDD）提供了一套强大且系统的方法论，帮助开发者构建复杂的软件系统。然而，由于其概念丰富、方法复杂，很多人在实践中容易走入误区。以下是一些常见的 DDD 实践误区分析，帮助避免在项目中“照猫画虎”地使用 DDD 而失去其真正价值。

## 1. 误区：为用而用，盲目引入 DDD

**问题表现**：

- 项目并不复杂，但强行套用 DDD 架构。
- 团队对 DDD 理解不深，却在项目初期就引入大量领域模型和分层结构。

**正确做法**：
DDD 适用于复杂领域的核心业务逻辑。若项目业务简单、变动小，用传统分层架构（如 MVC）可能更合适。应根据项目复杂度和团队成熟度选择合适的架构方法。

## 2. 误区：将所有类都建模为实体（Entity）

**问题表现**：

- 误认为所有对象都需要具有唯一标识（ID），导致领域模型臃肿。
- 不区分实体与值对象的职责。

**正确做法**：

- **实体（Entity）** 适合具有持续标识、生命周期的业务对象。
- **值对象（Value Object）** 更适合表达无身份但具有意义的概念，如“地址”“坐标”等。
  合理建模才能保持模型清晰、简洁。

## 3. 误区：将 Service 作为“万能垃圾桶”

**问题表现**：

- 所有业务逻辑都堆在 Application Service 或 Domain Service 中。
- 领域对象（如实体）变得贫血，只保留 getter/setter。

**正确做法**：
领域行为应该由领域对象自身承担，遵循“Tell, Don’t Ask”原则。Service 应该协调多个对象完成工作，而不是将所有业务逻辑集中处理。

## 4. 误区：忽略限界上下文（Bounded Context）

**问题表现**：

- 没有清晰划分上下文边界，所有模块共用模型。
- 不同业务语义混杂在一个模型中。

**正确做法**：
限界上下文是 DDD 的核心，确保每个模型的语言和规则在其边界内保持一致。通过清晰的上下文边界和集成模式（如 ACL、事件）实现上下文之间的协作。

## 5. 误区：防腐层滥用或缺失

**问题表现**：

- 外部系统接口直接引入到核心领域。
- 没有隔离第三方服务或遗留系统的模型差异。

**正确做法**：
在上下文或系统之间集成时，应使用防腐层（Anti-Corruption Layer）进行适配，避免外部变化污染内部模型。

## 6. 误区：领域事件滥用

**问题表现**：

- 过度发布不必要的领域事件，系统复杂度提升。
- 使用事件处理代替显式流程控制，难以追踪行为路径。

**正确做法**：
领域事件应表达**已发生的业务事实**，用于解耦上下文、异步通知等场景。不要用它们来代替清晰的流程控制或服务编排。

## 7. 误区：忽视通用语言建设

**问题表现**：

- 模型命名杂乱无章，开发人员使用不同术语表达相同概念。
- 领域专家和开发者之间缺乏有效沟通。

**正确做法**：
团队应与领域专家密切合作，共同构建**通用语言（Ubiquitous Language）**，并将其体现在代码中。代码即文档，统一术语有助于减少沟通成本和模型偏差。

## 8. 误区：领域模型代码即数据库模型

**问题表现**：

- 按照数据库表结构直接建模实体。
- 模型被数据库约束牵着走，不能表达业务含义。

**正确做法**：
领域模型关注业务语义，而非数据库设计。应优先从业务概念建模，再根据持久化需求设计映射策略（如使用 ORM 映射或数据转换层）。

## 9. 误区：认为 DDD 是架构风格

**问题表现**：

- 以为 DDD 只是“分层架构+聚合根+实体+仓储”的组合。
- 忽略 DDD 背后的建模思想与与领域紧密协作的重要性。

**正确做法**：
DDD 是一种**建模方法论**，不仅仅是代码结构的改变。它强调对业务的深入理解、与领域专家的协作，以及模型的持续演进与重构。

## 总结

DDD 的核心在于**领域建模与业务对齐**，不是一套“万能架构”。只有真正理解 DDD 的思想，并结合实际业务场景合理运用，才能发挥其价值。避免以上常见误区，是迈向高质量领域驱动设计的第一步。