领域驱动设计踩坑记录

ddd domain-modeling architecture microservices bounded-context
作者: 醉月思 发布日期: 2023-10-14 分类: 技术实践

如果只能用一句话说领域驱动设计：先把失败复现出来。

领域驱动设计（Domain-Driven Design，DDD）是一种软件设计方法学，它强调以领域为中心，通过将复杂的业务领域分解为多个子域，实现业务逻辑与技术实现的解耦。

引言

领域驱动设计（Domain-Driven Design，DDD）是一种软件设计方法学，它强调以领域为中心，通过将复杂的业务领域分解为多个子域，实现业务逻辑与技术实现的解耦。

DDD 不仅仅是技术方法论，更是一种思维方式。它要求开发者深入理解业务领域，构建领域模型，并通过限界上下文、聚合根、领域事件等模式，实现复杂业务逻辑的清晰表达和可靠实现。

本文将深入探讨 DDD 的核心概念、设计模式、实现策略以及在实际项目中的应用实践。

领域模型的本质

领域模型是 DDD 的核心，它是业务知识的抽象表示。

领域模型的价值

业务知识沉淀：领域模型将业务知识沉淀到代码中，避免知识散落在各个角落。

沟通语言统一：领域模型提供了团队沟通的通用语言，减少沟通误解。

业务逻辑集中：将业务逻辑集中在领域模型中，而非分散在多个服务中。

演进能力强：领域模型支持业务逻辑的持续演进，适应业务变化。

graph TB subgraph 业务现实 A[客户] B[订单] C[产品] D[支付] end subgraph 领域模型 E[Customer 实体] F[Order 聚合] G[Product 实体] H[Payment 服务] end subgraph 设计映射 I[业务概念] --> J[领域概念] K[业务规则] --> L[领域逻辑] M[业务流程] --> N[领域事件] end A --> E B --> F C --> G D --> H I --> J K --> L M --> N style E fill:#90EE90,stroke:#006400,stroke-width:1px style F fill:#87CEEB,stroke:#1E90FF,stroke-width:1px

模型驱动设计

模型优先：优先设计领域模型，基于模型编写代码。

迭代建模：通过不断的迭代完善领域模型，而非一次设计完成。

测试驱动：通过测试驱动的方式验证和演进领域模型。

重构友好：领域模型支持持续重构，保证代码质量。

限界上下文

限界上下文是 DDD 中最重要的概念之一，它解决了复杂系统的分解问题。

限界上下文的定义

上下文边界：限界上下文定义了业务领域的边界，每个上下文内部具有统一的语言和模型。

技术边界：限界上下文对应技术上的边界，如独立的服务或模块。

团队边界：限界上下文对应团队的边界，一个团队负责一个或几个限界上下文。

演进边界：限界上下文可以独立演进，不会相互影响。

graph TB subgraph 企业级限界上下文 A[企业上下文] A --> B[订单上下文] A --> C[库存上下文] A --> D[支付上下文] A --> E[用户上下文] end subgraph 上下文关系 F[订单上下文] G[库存上下文] H[支付上下文] F --> G{库存检查} F --> H{支付处理} style A fill:#87CEEB,stroke:#1E90FF,stroke-width:2px style F fill:#90EE90,stroke:#006400,stroke-width:1px

上下文映射

合作关系：不同上下文之间通过领域事件或 API 进行协作。

客户-供应商关系：一个上下文作为另一个上下文的客户端。

随需关系：按需调用其他上下文的功能。

防腐层：防腐层隔离外部上下文的模型，保护内部上下文。

共享内核：通过共享内核实现紧密协作的上下文。

sequenceDiagram participant Order as 订单上下文 participant Inventory as 库存上下文 participant Payment as 支付上下文 participant Shipping as 物流上下文 Order->>Inventory: 预占库存 Inventory-->>Order: 预占成功 Order->>Payment: 发起支付 Payment-->>Order: 支付成功 Order->>Order: 创建发货单 Order->>Shipping: 发起物流 Shipping-->>Order: 物流已安排 Note over Order,Shipping: 上下文协作流程

聚合与实体

聚合和实体是 DDD 中描述领域对象的核心概念。

实体的设计原则

唯一标识：每个实体都有唯一的标识符，这是实体的本质特征。

生命周期：实体有完整的生命周期，从创建到删除。

行为封装：实体的行为应该封装在实体内部，避免贫血模型。

不变量保护：实体的业务规则（不变量）应该在实体内部得到保护。

classDiagram class Order { -orderId: OrderId -customerId: CustomerId -status: OrderStatus -items: OrderItem[] -totalAmount: Money +placeOrder() +cancel() +addItem() +removeItem() +completePayment() +ship() } class OrderItem { -productId: ProductId -quantity: Quantity -price: Money +updateQuantity() +calculateTotal() } Order "1" -- "*" OrderItem : "*"

聚合的设计原则

一致性边界：聚合是一致性的边界，保证聚合内的数据一致性。

根实体：聚合根是聚合的唯一入口，外部只能通过聚合根访问聚合。

不变量保护：聚合的不变量应该在聚合根层面得到保护。

事务一致性：聚合的事务一致性通过聚合根来保证。

graph TB subgraph 聚合结构 A[聚合根: Order] A --> B[实体: OrderItem 1] A --> C[实体: OrderItem 2] A --> D[实体: OrderItem N] E[值对象: Money] F[值对象: Address] end subgraph 一致性边界 G[聚合边界] A --> G B --> G C --> G D --> G end subgraph 外部访问 H[外部服务] H --> A{通过聚合根访问} end style A fill:#90EE90,stroke:#006400,stroke-width:1px style G fill:#87CEEB,stroke:#1E90FF,stroke-width:1px

值对象

值对象是 DDD 中描述概念的轻量级对象。

值对象的特征

不变性：值对象创建后不可修改，任何变化都需要创建新对象。

相等性：值对象的相等性基于所有属性值的相等性。

无身份：值对象没有唯一标识，两个值对象属性值相同即相等。

可嵌套：值对象可以嵌套，构建复杂的值对象结构。

classDiagram class Money { -amount: BigDecimal -currency: Currency +add(other: Money): Money +subtract(other: Money): Money +multiply(factor: number): Money +equals(other: Object): boolean } class Address { -street: String -city: String -zipCode: String -country: Country +equals(other: Object): boolean } class Order { -shippingAddress: Address -billingAddress: Address } Order "1" "*" --> "1" Address : shippingAddress Order "1" "*" --> "2" Address : billingAddress

领域事件与事件风暴

领域事件是领域模型的重要组成部分，它记录了领域内发生的重要事情。

领域事件的特征

不可变性：领域事件创建后不可修改，保证事件的可靠性。

时间戳：领域事件包含事件发生的时间戳，用于时间排序。

领域版本：领域事件包含领域版本，用于防止版本混乱。

事件类型：领域事件有明确的类型，便于事件处理。

sequenceDiagram participant Order as 订单聚合 participant Event as 领域事件 participant Inventory as 库存上下文 participant Payment as 支付上下文 participant Notification as 通知服务 Order->>Order: 业务操作 Order->>Event: 生成领域事件 Event->>Inventory: 发布库存变更事件 Event->>Payment: 发布支付完成事件 Event->>Notification: 发布通知事件 Inventory->>Inventory: 订阅库存事件 Payment->>Payment: 订阅支付事件 Notification->>Notification: 订阅通知事件 Note over Order,Notification: 事件风暴机制

事件风暴模式

事件捕获：捕获领域内发生的所有事件。

事件发布：将事件发布到事件总线。

事件处理：订阅事件并处理事件的业务逻辑。

事件溯源：通过重放事件重建系统状态。

stateDiagram-v2 [*] --> 事件捕获 事件捕获 --> 事件发布 事件发布 --> 事件处理 事件处理 --> 事件溯源 事件溯源 --> [*] note right of 事件捕获 捕获领域内所有重要事件 end note note right of 事件发布 将事件发布到事件总线 end note note right of 事件处理 订阅并处理事件业务逻辑 end note

应用服务与领域服务

应用服务和领域服务是 DDD 中区分不同职责的服务类型。

应用服务的职责

用例编排：应用服务负责用例的编排和流程控制。

事务管理：应用服务管理事务的开始和提交。

外部服务调用：应用服务负责调用外部服务，处理技术细节。

DTO 转换：应用服务负责领域模型与 DTO 之间的转换。

领域服务的职责

业务逻辑：领域服务封装核心的业务逻辑，无状态。

领域规则：领域服务实现复杂的业务规则和计算。

复用性：领域服务设计时考虑复用性，避免重复逻辑。

领域纯度：领域服务应该纯粹关注领域逻辑，不应依赖外部服务。

graph TB subgraph 应用服务 A[订单创建应用服务] B[支付处理应用服务] C[库存检查应用服务] end subgraph 领域服务 D[价格计算服务] E[库存检查服务] F[风控检查服务] end subgraph 服务调用 G[应用服务] H[领域服务] I[外部服务] end A --> D B --> E C --> F G --> H H --> I style A fill:#87CEEB,stroke:#1E90FF,stroke-width:1px style D fill:#90EE90,stroke:#006400,stroke-width:1px style I fill:#FFD700,stroke:#DAA520,stroke-width:1px

存储库模式

存储库模式是 DDD 中抽象数据访问的核心模式。

存储库接口

面向集合：存储库接口表现为领域对象的集合，支持基本的 CRUD 操作。

聚合访问：存储库主要操作聚合，通过聚合根操作聚合内部对象。

持久化细节：存储库封装持久化细节，使领域模型与持久化机制解耦。

事务边界：存储库通常作为事务边界的一部分。

classDiagram class Repository { <<interface>> +findById(id: ID): Entity +findAll(): Entity[] +save(entity: Entity): void +delete(id: ID): void } class OrderRepository { <<interface>> +findById(orderId: OrderId): Order +findByCustomerId(customerId: CustomerId): Order[] +save(order: Order): void } class OrderRepositoryImpl { -orderDao: OrderDao +findById(orderId: OrderId): Order +save(order: Order): void } Repository <|.. OrderRepository OrderRepositoryImpl ..| OrderRepository

聚合存储库

聚合根操作：聚合存储库只操作聚合根，不直接操作聚合内部对象。

完整性保护：聚合存储库保证聚合的完整性，包括所有内部对象。

事务管理：聚合存储库管理聚合的事务边界，保证聚合的一致性。

性能优化：聚合存储库可以通过预加载、延迟加载等技术优化性能。

战术架构设计

DDD 的技术架构设计需要支持领域模型的实现。

分层架构

用户界面层：处理用户交互，将请求传递给应用层。

应用层：用例编排，调用领域服务，管理事务。

领域层：实现核心业务逻辑，包含领域模型和领域服务。

基础设施层：提供技术基础设施支持，如数据库访问、外部服务调用等。

graph TB subgraph DDD 分层架构 A[用户界面层] B[应用层] C[领域层] D[基础设施层] end subgraph 各层职责 E[用户交互] F[用例编排] G[业务逻辑] H[技术实现] end A --> E B --> F C --> G D --> H A --> B B --> C C --> D style A fill:#90EE90,stroke:#006400,stroke-width:1px style C fill:#FFD700,stroke:#DAA520,stroke-width:1px style D fill:#87CEEB,stroke:#1E90FF,stroke-width:1px

微服务架构与 DDD

限界上下文映射：限界上下文直接映射为微服务。

领域事件驱动：微服务通过领域事件进行异步协作。

独立部署：每个微服务可以独立部署和扩展。

团队自治：每个微服务由独立团队负责，团队自治决策。

graph TB subgraph 微服务架构 A[订单服务] B[库存服务] C[支付服务] D[物流服务] E[通知服务] end subgraph 事件总线 F[领域事件总线] end subgraph 服务关系 G[订单服务] H[库存服务] I[支付服务] J[物流服务] end A --> G B --> H C --> I D --> J E --> F G --> F{订单创建} H --> F{库存扣减} I --> F{支付完成} J --> F{物流安排} style F fill:#87CEEB,stroke:#1E90FF,stroke-width:1px

实施策略

DDD 的实施需要考虑团队、技术、业务等多个因素。

渐进式实施

从局部开始：从核心业务领域开始，逐步扩展到整个系统。

团队培训：培训团队成员的 DDD 知识和技能。

工具支持：选择合适的工具支持 DDD 的实施。

持续改进：基于实施经验持续改进 DDD 实践。

技术选型

编程语言：选择支持面向对象编程范式的语言。

框架支持：选择支持 DDD 设计模式的框架。

ORM 工具：选择支持领域模型持久化的 ORM 工具。

事件驱动：选择支持事件驱动的消息中间件。

反模式与陷阱

DDD 的实施中存在一些常见的反模式和陷阱。

常见反模式

贫血领域模型：领域对象只有 getter/setter，没有业务行为。

万能领域模型：领域模型过于庞大，职责不清。

上下文过度拆分：为了技术而过度拆分限界上下文。

事件过度使用：为了解耦而滥用领域事件。

实施陷阱

忽视业务价值：过度关注技术实现，忽视业务价值。

照搬照抄：盲目照搬其他项目的 DDD 设计，不考虑业务差异。

过度设计：为未来需求设计过于复杂的结构，增加复杂度。

忽视技术债务：忽视技术债务的积累，导致系统难以维护。

最佳实践总结

DDD 的最佳实践是多年经验的结晶。

建模原则

业务驱动：以业务需求为驱动，避免技术驱动的过度设计。

模型演进：通过迭代建模不断完善领域模型。

团队合作：通过领域建模加强团队协作。

持续重构：持续重构代码，保持代码质量。

架构原则

分层清晰：保持架构层次清晰，职责分明。

依赖合理：合理设计组件间的依赖关系。

可测试性：设计可测试的架构，提高代码质量。

可扩展性：设计可扩展的架构，适应业务增长。

团队协作

跨职能团队：组建包含业务和技术人员的跨职能团队。

知识共享：通过建模会议、代码审查等方式共享知识。

持续学习：鼓励团队成员持续学习和实践 DDD。

质量文化：建立重视代码质量和技术债务的质量文化。

未来发展趋势

DDD 的理念和实践仍在不断发展，未来的趋势包括：

与新技术的融合

Serverless DDD：在 Serverless 架构中应用 DDD 的设计理念。

事件驱动架构：与事件驱动架构深度集成，构建事件驱动的分布式系统。

微前端集成：结合微前端技术，实现前端领域的 DDD 实践。

AI 辅助建模：利用 AI 技术辅助领域建模和设计决策。

工具化与自动化

建模工具：提供可视化的领域建模工具，提高建模效率。

代码生成：基于领域模型自动生成代码，减少重复工作。

测试生成：基于领域模型自动生成测试，提高测试覆盖率。

文档自动生成：基于领域模型自动生成技术文档。

理论发展

新兴概念：探索和引入新兴的概念和模式。

实践总结：总结实践经验，形成新的理论和方法。

跨领域应用：将 DDD 的理念和原则应用到其他领域。

教育普及：通过教育和培训提高 DDD 的认知度和接受度。

结论

领域驱动设计是一种深刻的软件设计方法论，它要求我们深入理解业务领域，构建能够表达业务逻辑的领域模型。通过限界上下文、聚合根、领域事件等模式，DDD 为复杂系统的设计提供了强大的理论支持和实践指导。

DDD 的成功实施需要在业务、技术、团队等多个层面协同努力。业务深入理解是 DDD 的基础，技术选型和架构设计是 DDD 的支撑，团队协作和文化建设是 DDD 的保障。

在数字化转型的过程中，业务复杂度不断增长，传统的以技术为中心的设计方法已经无法应对。DDD 提供了一种以业务为中心的设计思想，帮助我们构建更加健壮、可演进、可理解的软件系统。

未来，随着新技术和新模式的出现，DDD 的理念和实践将继续发展和完善。对于技术团队而言，掌握 DDD 的原理和实践，是构建高质量、可持续软件系统的核心能力。

在软件工程的历史中，设计思想的演进总是伴随着抽象层次的提升。DDD 代表了以业务为中心、以模型为核心的设计思想的演进，它为我们在复杂业务环境中构建可靠的软件系统提供了强大工具。深入理解 DDD 的原理和实践，有助于我们做出更好的技术决策，构建更加优秀的软件系统。

本文深入探讨了领域驱动设计的核心概念，包括领域模型、限界上下文、聚合实体、值对象、领域事件、应用服务与领域服务的区分，以及存储库模式和技术架构设计，并通过 Mermaid 图表展示了业务到模型的映射、限界上下文划分、上下文协作、实体关系、聚合结构、应用与领域服务调用、分层架构以及微服务事件驱动协作。

版权声明: 本文首发于 指尖魔法屋-领域驱动设计踩坑记录（https://blog.thinkmoon.cn/post/39-ddd-domain-driven-design-practice/） 转载或引用必须申明原指尖魔法屋来源及源地址！

相关阅读

根据标签、分类和主题为你挑选的相近文章

把单体换到分布式系统时踩过的坑
拆成五个微服务之后，下单接口偶发「扣了库存没生成订单」——链路一查，超时重试把同一笔请求打了两次。单体时代四十分钟部署的痛，换了一种更隐蔽的形式回来。
📁 技术实践
📅 2022-10-07