《中台架构与实现-基于DDD和微服务》- 读后感 - 第6天打卡-南黎1

南黎1 2022-03-05 11:52:34

DDD定义
领域驱动设计(Domain Driven Design，DDD)是一种面向对象建模的方法，融合了软件需求分析和系统设计，被用来进行软件系统设计与分析。在系统设计过程中，DDD 优先考虑的是领域模型，其次才是数据和行为，是以模型驱动设计为根基，以软件领域为着眼点，专注于领域模型的构建与代码匹配的新型开发方式。DDD可以指导微服务的边界划分与设计。
领域驱动设计包括战略设计模式和战术设计模式。它们分别从不同的视角出发，完成领域建模和微服务的拆分和设计。

战略设计是从业务视角出发，划分业务的领域边界，建立基于通用语言和业务上下文语义边界的限界上下文，构建领域模型。而限界上下文就可以作为微服务拆分和设计的边界。
战术设计则是从技术视角出发，侧重于对领域模型的技术实现，按照领域模型完成微服务的开发和落地。在战术设计中会有聚合、聚合根、实体、值对象、领域服务、领域事件、应用服务和仓储等领域对象，这些领域对象会以代码的形式映射到微服务中，完成设计和系统落地。
下面我们不妨先来看看，DDD是如何进行战略设计的?

一、战略设计模式
战略设计模式是系统的业务框架设计，战略设计主要从业务视角出发，划分领域边界，建立通用语言的限界上下文，构建业务领域模型，限界上下文可以作为微服务设计的参考边界，保证了领域模型的完整性，通过战略设计模式设计出系统的主业务框架。

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

（1）、限界上下文

DDD 在战略设计上提出了限界上下文用来确定语义所在的领域边界。限界上下文分为限界和上下文，限界就是领域的边界，而上下文则是语义环境。通过领域的限界上下文，明确了领域内相关术语的含义。这个边界定义了模型的适用范围，使团队所有成员能够明确地知道什么应该在模型中实现，什么不应该在模型中实现。限界上下文就是微服务的边界，将限界上下文内的领域模型映射到微服务，就完成了从问题域到软件的解决方案。限界上下文是微服务设计和拆分的主要依据。

（2）、领域和子域

领域是用来确定范围的，范围即边界，这也是 DDD 在设计中不断强调边界的原因，领域可以进一步划分为子领域。划分出来的子领域称为子域，每个子域对应一个更小的问题或更小的业务范围。子域根据自身重要性和功能属性划分为三类子域，他们分别是：核心域、通用域和支撑域。

领域的核心思想就是将问题域逐级细分，来降低业务理解和系统实现的复杂度。通过领域细分，逐步缩小微服务需要解决的问题域，构建合适的领域模型，而领域模型映射成系统就是微服务。既对一个问题不断的划分，直到划分为熟悉的，能够快速处理的小问题。然后再对小问题进行优先级排列。在领域细分到一定的范围后，对这个子域进行事件风暴，为这个子域划分限界上下文，建立领域模型，针对领域模型进行微服务设计。

（3）、核心域、通用域和支撑域

核心域、支撑域和通用域的主要目标是通过领域划分，区分不同子域在公司内的不同功能属性和重要性，从而公司可对不同子域采取不同的资源投入和建设策略，其关注度也会不一样。

核心域是决定产品和公司竞争力的子域，是成功的主要因素和公司的核心竞争力。

通用域是同时被多个子域使用的通用功能子域。

支撑域是指不包含决定产品和公司核心竞争的功能，也不包含通用功能的子域。具有企业特性，而不具有通用性，例如数据代码类的数据字典系统等。

二、战术设计模式
战术设计定义微服务模块的具体实现，确定微服务中的功能及其依赖关系与微服务的代码结构。战术设计包含对实体、值对象、聚合和聚合根的设计。

DDD 领域建模通常通过事件风暴，采用用例分析、场景分析和用户旅程分析等方法，通过头脑风暴列出所有可能的业务行为和事件，然后找出产生这些行为的领域对象，并梳理领域对象之间的关系，找出聚合根，找出与聚合根业务紧密关联的实体和值对象，再将聚合根、实体和值对象组合，构建聚合。

（1）、值对象

值对象本质上是一个集合，这个集合中有若干个用于描述目的、具有整体概念和不可修改的属性，在领域建模的过程中，值对象可以保证属性归类的清晰和概念的完整性，避免属性零碎。

比如人员实体原本包括：姓名、年龄、性别以及人员所在的省、市、县和街道等属性，可以将省、市、县和街道等属性拿出来构成一个“地址属性集合”，这个集合就是值对象了。实体和值对象是微服务底层的最基础的对象，一起实现实体最基本的核心领域逻辑。

（2）、聚合

聚合是领域模型中能够让实体和值对象协同工作的组织，聚合用来确保实体与值对象这些领域对象在实现共同的业务逻辑时，同时能够保证数据的一致性。聚合由业务和逻辑紧密关联的实体和值对象组合而成，是数据修改和持久化的基本单元，每一个聚合对应一个仓储，实现数据的持久化。聚合有一个聚合根和上下文边界，上下文边界用来定义聚合内部的实体和值对象，按照这种方式设计微服务满足微服务设计的“高内聚、低耦合”原则。

聚合是领域模型中最底层的边界，可以作为拆分微服务的最小单位

（3）、聚合根

如果把聚合比作组织，那聚合根就是这个组织的负责人。聚合根也称为根实体，聚合根不仅是实体，还是聚合的管理者。

领域建模
在了解基本概念之后，我们以系统中的用户管理功能为例构建领域建模，加深对概念的理解

场景描述：系统管理员在登录系统之后，创建用户账户，并设置用户初始密码，打开菜单管理页面，为不同的岗位分配权限。用户登录成功后，系统将记录用户的操作到日志文件中，

第一步：找出实体和值对象。根据场景分析，分析并找出发起或产生这些命令和领域事件的实体与值对象，将与实体或值对象有关的命令和事件聚集到实体。通过分析，找到了：用户、账户、系统、菜单和用户日志等实体和值对象。

第二步：定义聚合。定义聚合前，先找出聚合根。找出“用户”和“系统”两个聚合根。通过聚合与聚合根紧密依赖的关系分析。找出用户日志和用户紧密关联，菜单和系统紧密关联。经过分析，用户管理子系统中建立了系统和用户信息两个聚合。其中系统聚合有系统、菜单等实体。用户信息聚合有用户日志、用户信息、账户等实体。

第三步：定义限界上下文。

划定限界上下文，根据上下文语义将聚合归类。根据用户域的上下文语境，用户基本信息和用户日志信息这两个聚合共同构成用户信息域，分别管理用户基本信息、用户登录和操作日志。系统功能和菜单这两个聚合共同构成权限域，实现系统和菜单管理。根据业务边界，将用户中台划分为两个限界上下文：用户信息、系统。

因此根据限界上下文与功能职责就将用户管理系统拆分为系统与用户两个微服务。

...全文