first commit

doc/领域驱动设计.md

@@ -0,0 +1,186 @@
+# 领域驱动设计
+
+领域驱动设计（Domain-Driven Design，DDD）是由埃里克・埃文斯（Eric Evans）提出的一种软件开发方法论，核心是通过深入理解业务领域，将业务逻辑与技术实现紧密结合，从而构建出灵活、可维护且贴合业务的复杂系统。它尤其适合业务逻辑复杂、需求多变的大型应用（如金融、电商、企业 ERP 等）。
+
+### **一、DDD 的核心思想**
+
+DDD 的核心是 “以领域为中心”，强调开发团队与业务专家深度协作，共同挖掘业务本质（领域知识），并将这些知识转化为软件设计。其目标是：
+
+
+*   解决复杂业务逻辑的建模问题；
+
+*   让软件设计直接反映业务规则，降低技术与业务的鸿沟；
+
+*   提高系统的可扩展性和可维护性。
+
+### **二、DDD 的核心概念**
+
+DDD 通过一系列概念将领域知识结构化，核心概念包括：
+
+#### 1. **领域（Domain）**
+
+业务所涉及的范围和知识集合，是问题的核心。例如，电商领域包括商品、订单、支付、物流等子领域。
+
+#### 2. **子领域（Subdomain）**
+
+将复杂领域拆分为更小的、可管理的子领域，分为三类：
+
+
+
+*   **核心子领域**：业务的核心竞争力（如电商的订单履约），需重点投入设计；
+
+*   **支撑子领域**：支持核心业务但非核心（如用户评价），可适度设计；
+
+*   **通用子领域**：多个子领域共享的功能（如日志、权限），可使用通用组件或第三方工具。
+
+#### 3. **限界上下文（Bounded Context）**
+
+
+
+*   **定义**：领域模型的边界，在边界内，领域术语、规则、对象的含义是统一的（即 “通用语言”），边界外可能有不同的模型。
+
+*   **作用**：解决领域模型的歧义性（例如，“订单” 在电商订单系统和财务系统中可能有不同含义），是微服务拆分的重要依据（通常一个限界上下文对应一个微服务）。
+
+#### 4. **通用语言（Ubiquitous Language）**
+
+
+
+*   开发团队与业务专家共同定义的语言，包含术语、规则、流程，需贯穿需求分析、设计、编码、测试的全流程。
+
+*   例如，在电商领域，“下单”“库存锁定”“支付回调” 等术语需在团队中达成共识，避免歧义。
+
+#### 5. **领域模型（Domain Model）**
+
+对领域知识的抽象表示，是 DDD 的核心。领域模型通过 “实体”“值对象”“聚合” 等元素构成。
+
+#### 6. **实体（Entity）**
+
+
+
+*   具有唯一标识（ID），且其生命周期中标识不变的对象，状态可变化。
+
+*   例如：“用户”（ID 唯一，姓名、地址可变）、“订单”（订单号唯一，状态可从 “待支付” 变为 “已发货”）。
+
+#### 7. **值对象（Value Object）**
+
+
+
+*   无唯一标识，仅通过属性值来定义，不可变（一旦创建，属性不可修改）。
+
+*   用于描述实体的属性或状态。例如：“地址”（由省、市、街道等属性组成，无独立 ID）、“金额”（由数值和货币单位组成）。
+
+#### 8. **聚合（Aggregate）**
+
+
+
+*   一组紧密关联的实体和值对象的集合，作为数据修改和事务的最小单元（“聚合根” 是聚合的入口）。
+
+*   目的：保证领域模型的一致性，避免复杂的跨对象事务。
+
+*   **聚合根（Aggregate Root）**：聚合中唯一对外暴露的实体，外部只能通过聚合根访问聚合内的其他对象。例如，“订单” 是聚合根，包含 “订单项”（实体）和 “收货地址”（值对象），外部需通过订单 ID 操作订单项。
+
+#### 9. **领域服务（Domain Service）**
+
+
+
+*   当业务逻辑不属于某个实体或值对象时，将其封装为领域服务（无状态，仅处理领域逻辑）。
+
+*   例如：“订单结算” 涉及订单、支付、库存多个聚合，需通过领域服务协调。
+
+#### 10. **领域事件（Domain Event）**
+
+
+
+*   领域中发生的重要事件（如 “订单支付成功”“库存不足”），用于捕获领域中的状态变化，实现跨聚合 / 限界上下文的通信。
+
+*   例如：订单支付成功后，发布 “OrderPaidEvent”，库存系统监听事件并扣减库存，物流系统监听并创建物流单。
+
+#### 11. **仓储（Repository）**
+
+
+
+*   封装对聚合的持久化操作（如保存、查询），隔离领域模型与数据存储细节（如数据库、缓存）。
+
+*   仓储仅针对聚合根设计，例如 “OrderRepository” 负责订单聚合的持久化。
+
+#### 12. **工厂（Factory）**
+
+
+
+*   用于创建复杂的领域对象（如聚合），封装创建逻辑，避免领域模型被创建逻辑污染。
+
+### **三、DDD 的分层架构**
+
+为了隔离关注点，DDD 通常采用分层架构（与传统三层架构不同，更强调领域层的核心地位）：
+
+
+
+1.  **用户界面层（UI Layer）**
+
+*   负责与用户交互（如 API 接口、网页、APP），处理输入输出，不包含业务逻辑。
+
+1.  **应用层（Application Layer）**
+
+*   协调领域层完成业务用例（如 “下单流程” 需调用订单聚合、支付服务、库存服务），无业务规则，仅负责流程编排。
+
+*   依赖领域层，不依赖基础设施层（通过依赖注入反转）。
+
+1.  **领域层（Domain Layer）**
+
+*   核心层，包含领域模型（实体、值对象、聚合、领域服务、领域事件等），封装业务规则和逻辑。
+
+*   不依赖其他层（基础设施层的依赖通过接口反转）。
+
+1.  **基础设施层（Infrastructure Layer）**
+
+*   提供技术支持（如数据库持久化、消息队列、缓存、第三方服务集成）。
+
+*   实现领域层定义的接口（如 Repository 的数据库实现），支撑应用层和领域层的运行。
+
+### **四、DDD 的实践流程**
+
+
+
+1.  **事件风暴（Event Storming）**：业务专家与开发团队通过头脑风暴，梳理领域中的事件、命令、实体、聚合等，划分限界上下文，形成通用语言。
+
+2.  **领域建模**：在限界上下文内，设计实体、值对象、聚合等领域模型，明确聚合根和领域服务。
+
+3.  **分层实现**：按分层架构编码，领域层优先实现，基础设施层提供技术支撑。
+
+4.  **持续迭代**：通过反馈优化模型，确保领域模型与业务同步演进。
+
+### **五、DDD 与微服务的关系**
+
+DDD 是微服务拆分的重要指导思想：
+
+
+
+*   限界上下文是微服务的天然边界（一个限界上下文通常对应一个微服务），确保服务内模型一致，服务间通过接口或事件通信。
+
+*   微服务的独立部署、扩展特性，与 DDD 隔离领域复杂度的目标一致。
+
+### **六、DDD 的优势与挑战**
+
+
+
+*   **优势**：
+
+
+    *   模型贴近业务，易理解和维护；
+
+    *   隔离复杂业务，提高系统扩展性；
+
+    *   减少技术与业务的沟通成本。
+
+*   **挑战**：
+
+
+    *   学习成本高（概念多且抽象）；
+
+    *   适合复杂业务，简单系统可能过度设计；
+
+    *   依赖团队与业务专家的深度协作，对团队能力要求高。
+
+### **总结**
+
+DDD 不是一套固定的工具或框架，而是一种 “以业务为中心” 的思维方式。它通过领域建模将复杂业务拆解为可管理的部分，帮助团队构建出既满足业务需求又具备技术灵活性的系统。对于业务复杂、长期演进的系统，DDD 是值得投入的设计方法。