DDD领域驱动设计

领域驱动设计（Domain-Driven Design，DDD）是一种面向复杂业务系统建模和架构设计的方法论，由 Eric Evans 在他的经典著作《Domain-Driven Design: Tackling Complexity in the Heart of Software》中提出。

---

✳️ 简单来说：DDD 是什么？

DDD 的核心目标是：把业务复杂性和技术复杂性分离，围绕业务建模，实现高内聚、低耦合、可演化的系统。

---

🔧 举个实际开发类比：

你过去可能是这样开发的（三层架构）：

nginx

复制编辑

Controller → Service → Repository → DbContext

代码关注点主要在数据库表、字段和功能实现上。

而 DDD 则是从“业务的语言、业务规则、业务行为”出发设计系统，强调：

“用代码表达业务模型，而不是数据库结构。”

---

🧩 DDD 的核心概念（非常重要）

名称	说明
实体（Entity）	有唯一标识、生命周期的业务对象，例如用户、订单、文章等。
值对象（Value Object）	无唯一 ID，按值判断相等，例如坐标、金额、地址等。
聚合根（Aggregate Root）	一组业务相关对象的统一入口，外部只能通过它访问内部对象。
领域服务（Domain Service）	不属于某个实体，但体现业务行为的服务，例如转账操作。
仓储（Repository）	封装持久化操作的接口，提供实体的保存、查询、删除等方法。
应用服务（Application Service）	调用领域服务或聚合，实现具体用例逻辑，对外暴露接口。
领域事件（Domain Event）	表示业务中的某个事件发生了，如“订单已支付”。
防腐层（Anti-Corruption Layer）	屏蔽外部系统的影响，保持核心领域模型的纯洁性。

 

---

🧱 一个典型的 DDD 分层架构

plaintext

复制编辑

App.API <- 控制器 (WebAPI) │ ├── Application <- 应用层（处理用例，协调服务） │ └── Services │ └── DTOs │ ├── Domain <- 领域层（核心业务逻辑） │ └── Entities │ └── ValueObjects │ └── Interfaces (Repository、DomainService) │ ├── Infrastructure <- 基础设施层（数据库、缓存、文件等技术细节） │ └── EF Repository 实现 │ └── Redis、HttpClient 等

---

✅ DDD 与传统三层架构的区别

对比项	三层架构（传统）	领域驱动设计（DDD）
关注点	技术结构、表结构	业务逻辑、领域模型
实体定义	和数据库表结构一致	反映业务概念
业务逻辑	写在 Service 或 Controller 中	放在实体或领域服务中
可扩展性	差，耦合高	高，职责清晰
项目结构	Controller / Service / Repository	分层清晰（App / Domain / Infra）

 

---

🧠 为什么要学/用 DDD？

1. 🚀 复杂业务逻辑清晰可维护

2. 🔄 可以更容易进行单元测试

3. 🧩 分层清晰、职责单一

4. 🔌 更容易做微服务/模块化演进

5. 🗣️ 统一团队语言（Ubiquitous Language）

---

📦 简单例子

以权限为例：

DDD 思路：

• 实体：UserPermission（表示用户拥有某个权限）

• 值对象：PermissionCode

• 聚合根：User（通过它管理权限）

• 仓储接口：IUserPermissionRepository

• 应用服务：PermissionService

• 基础设施：Redis 或 EF 实现 Repository

---

✅ 总结一句话

DDD 不是追求复杂结构，而是为了把复杂的业务变得结构清晰、演化可控。