领域驱动模型设计（一）

目录

三层架构

领域驱动设计的五层架构

微服务为什么要选择DDD？

DDD 与微服务的关系

与微服务架构相得益彰

---

三层架构

我们平时的开发流程通常分为下面的三个步骤：

1. 技术选型，搭建基础技术框架。如我们使用java作为开发语言，使用SpringBoot、SpringCloud等框架，采用redis、mq等中间件，使用mysql、es存储数据。
2. 然后我们搭建了基础的开发环境后，会在数据库中建表，然后用表数据映射到我们的数据实体。
3. 采用mvc三层架构的模型开发我们的业务逻辑，所有业务逻辑写在service中，我们的实体通常只作为service操作的数据载体。

下图是三层架构中我们主要的工程结构：

在小的项目中我们采用这种开发模式没有多大问题，比较方便快捷。但是随着业务逻辑复杂后，service层的逻辑变得臃肿不堪，一个service中有几千行的代码，并且代码的意图不再明显，慢慢的发现我们开发的流程变成了面向过程开发。

我们脱离了面向对象开发，我们学习的设计模式也不能在这种结构中使用，重复逻辑的抽离，公共的可复用领域服务独立等问题。

我们将这种情况称为由贫血症引起的失忆症。那么有没有更好的架构和方法，来应对复杂开发的演进呢？软件建模大佬eric早已为我们想好，并提出了领域驱动模型设计的方法论。

领域模型的开发方式，将数据和行为封装在一起，并与现实世界中的业务对象相映射。各类具备明确的职责划分，将领域逻辑分散到领域对象中。

领域驱动设计的五层架构

架构的演进过程：

在领域驱动模型设计中通常采用严格分层架构模式，上层只对下层依赖。并且采用依赖倒置原则，业务不再依赖基础设施，而是基础设施层依赖我们的领域服务，一切围绕领域服务。

下图是领域驱动设计工程实践中常用的五层分层架构模型：

api接口层：是很薄的一层做参数校验和应用服务调用；

应用服务层：领域服务的流程编排和输出数据类型转换（do -> dto）；

上下文：在领域服务中做数据流转的载体；

领域服务层：核心业务逻辑的处理；

基础设施层：包括仓储服务、缓存设施、消息队列等。

微服务为什么要选择DDD？

DDD 核心思想是通过领域驱动设计方法定义领域模型，从而确定业务和应用边界，保证业务模型与代码模型的一致性。

DDD 不是架构，而是一种架构设计方法论，它通过边界划分将复杂业务领域简单化，帮我们设计出清晰的领域和应用边界，可以很容易地实现架构演进。

DDD 包括战略设计和战术设计两部分。

战略设计主要从业务视角出发，建立业务领域模型，划分领域边界，建立通用语言的限界上下文，限界上下文可以作为微服务设计的参考边界。

战术设计则从技术视角出发，侧重于领域模型的技术实现，完成软件开发和落地，包括：聚合根、实体、值对象、领域服务、应用服务和资源库等代码逻辑的设计和实现。

事件风暴是建立领域模型的主要方法，它是一个从发散到收敛的过程。它通常采用用例分析、场景分析和用户旅程分析，尽可能全面不遗漏地分解业务领域，并梳理领域对象之间的关系，这是一个发散的过程。事件风暴过程会产生很多的实体、命令、事件等领域对象，我们将这些领域对象从不同的维度进行聚类，形成如聚合、限界上下文等边界，建立领域模型，这就是一个收敛的过程。

我们可以用三步来划定领域模型和微服务的边界。

第一步：在事件风暴中梳理业务过程中的用户操作、事件以及外部依赖关系等，根据这些要素梳理出领域实体等领域对象。

第二步：根据领域实体之间的业务关联性，将业务紧密相关的实体进行组合形成聚合，同时确定聚合中的聚合根、值对象和实体。在这个图里，聚合之间的边界是第一层边界，它们在同一个微服务实例中运行，这个边界是逻辑边界，所以用虚线表示。

第三步：根据业务及语义边界等因素，将一个或者多个聚合划定在一个限界上下文内，形成领域模型。在这个图里，限界上下文之间的边界是第二层边界，这一层边界可能就是未来微服务的边界，不同限界上下文内的领域逻辑被隔离在不同的微服务实例中运行，物理上相互隔离，所以是物理边界，边界之间用实线来表示。

DDD 与微服务的关系

DDD 是一种架构设计方法，微服务是一种架构风格

两者从本质上都是为了追求高响应力，而从业务视角去分离应用系统建设复杂度的手段。两者都强调从业务出发，其核心要义是强调根据业务发展，合理划分领域边界，持续调整现有架构，优化现有代码，以保持架构和代码的生命力，也就是我们常说的演进式架构。

DDD 主要关注：从业务领域视角划分领域边界，构建通用语言进行高效沟通，通过业务抽象，建立领域模型，维持业务和代码的逻辑一致性。

微服务主要关注：运行时的进程间通信、容错和故障隔离，实现去中心化数据管理和去中心化服务治理，关注微服务的独立开发、测试、构建和部署。

与微服务架构相得益彰

在解决大型系统问题时通常分治来拆解问题：一般有两种方式，技术维度和业务维度。技术维度是类似MVC这样，业务维度则是指按业务领域来划分系统。

架构设计活动精简为以下三个层面：

• 业务架构——根据业务需求设计业务模块及其关系
• 系统架构——设计系统和子系统的模块
• 技术架构——决定采用的技术及框架

分层架构套（先确定系统架构），或者用PHP开发很快（先确定技术架构）。

跳过业务架构设计出来的架构关注点不在业务响应上，可能就是个大泥球，在面临需求迭代或响应市场变化时就很痛苦。

DDD的核心诉求就是将业务架构映射到系统架构上，在响应业务变化调整业务架构时，也随之变化系统架构。而微服务追求业务层面的复用，设计出来的系统架构和业务一致；在技术架构上则系统模块之间充分解耦，可以自由地选择合适的技术架构，去中心化地治理技术和数据。

设计领域模型的一般步骤如下：

1. 根据需求划分出初步的领域和限界上下文，以及上下文之间的关系；
2. 进一步分析每个上下文内部，识别出哪些是实体，哪些是值对象；
3. 对实体、值对象进行关联和聚合，划分出聚合的范畴和聚合根；
4. 为聚合根设计仓储，并思考实体或值对象的创建方式；
5. 在工程中实践领域模型，并在实践中检验模型的合理性，倒推模型中不足的地方并重构。

下一篇：领域驱动模型设计（二）_张家老院子的博客-CSDN博客