DDD（Domain-Driven Design，领域驱动设计）是一种 软件架构和建模方法论，由 Eric Evans 在《领域驱动设计：软件核心复杂性应对之道》一书中提出。它主要解决的是：当业务足够复杂时，如何用代码去 清晰表达业务领域，避免“业务逻辑散落在各个层里、难以维护和扩展”的问题。

🔑 DDD 的核心思想

一句话总结：
以业务为核心，用领域模型驱动系统设计，让代码结构与业务语言一致。

🏗️ DDD 的分层架构

DDD 并不是一个具体的框架，而是一种架构思想。通常会结合 分层架构 来落地：

1. 用户接口层（Interface Layer / Presentation Layer）

• 负责与外部交互（UI、API、消息队列等）

• 接收请求、返回响应，但不包含业务逻辑

2. 应用层（Application Layer）

• 负责 应用服务编排，协调领域对象完成业务

• 不包含复杂的业务逻辑，主要是“流程控制器”

• 例如：订单下单服务，会调用库存、支付、物流等领域服务

3. 领域层（Domain Layer）✅ 核心

• 业务逻辑的核心所在

• 包含：

  • 实体（Entity）：有唯一标识的业务对象（如订单、用户）

  • 值对象（Value Object）：无唯一标识，仅由值决定相等性（如地址、金额）

  • 聚合（Aggregate）：业务边界，聚合根负责维护聚合内一致性（如订单聚合：订单头 + 订单行）

  • 领域服务（Domain Service）：当逻辑不适合放在实体/值对象里时，用服务表达（如价格计算）

  • 领域事件（Domain Event）：业务发生的事实，可被异步订阅（如订单已支付）

4. 基础设施层（Infrastructure Layer）

• 提供技术支持（数据库、缓存、消息、第三方服务等）

• 具体实现细节放在这里

• 领域层依赖接口，基础设施层实现接口（依赖倒置）

📦 DDD 的战术与战略

DDD 分为两个层面：

战术设计（Tactical Design）

• 聚焦代码实现

• 包括：实体、值对象、聚合、仓储（Repository）、领域服务、领域事件等

战略设计（Strategic Design）

• 聚焦业务整体建模

• 限界上下文（Bounded Context）：给不同业务领域划清边界，避免“大泥球”

  • 例：电商系统有 订单上下文、库存上下文、用户上下文

• 上下文映射（Context Mapping）：不同上下文之间的关系和依赖

  • 例：订单依赖库存 → 订单上下文 调用 库存上下文 API

⚡ DDD 的优点

1. 业务逻辑清晰：代码结构与业务高度一致

2. 降低复杂度：通过限界上下文和聚合边界划分

3. 演进性好：方便扩展和维护

4. 跨团队沟通：统一业务语言（Ubiquitous Language），开发和业务人员都能理解

🚀 总结

DDD 的精髓就是：
👉 复杂业务领域 → 建立统一语言 → 划分上下文 → 分层架构 → 聚合建模 → 用代码还原业务。