DDD领域驱动设计落地实践系列：战略设计和战术设计

引言

DDD大致实现过程

如下图所示，实现DDD落地大致需要经历这样三个阶段，即为业务分析-》战略设计-》战术设计，不同阶段的输出都是下一阶段的输入。业务分析阶段为战略设计输出经过统一语言描述的业务事件、业务逻辑以及业务分类，而战略设计阶段又为战术设计阶段输入领域模型以及边界上下文，方便其进行微服务拆分以及模型映射。下面我们分别看下这三个阶段到底都做了什么事情。

业务分析：在这个阶段需要集齐项目团队的成员主要包括领域专家、设计人员、开发人员等一起对业务问题域以及业务期望进行全面的梳理，厘请业务中的统一语言，在业务领域中发现领域事件、领域对象及其对应的领域行为，搞清楚他们各自的关联关系。

战略设计：通过DDD的理论，对业务进行领域划分构建领域模型，梳理出相应的限界上下文，通过统一的领域语言从战略层面进行领域划分以及构建领域模型。在构建领域模型的过程中需要梳理出对应的聚合、实体、以及值对象。

战术设计：以领域模型为战术设计的输入，以限界上下文作为微服务划分的边界进行微服务拆分，在每个微服务中进行领域分层，实现领域模型对于代码的映射，从而实现DDD的真正落地实施。

实体
和值对象不同的是，实体是有唯一标识的，这就好比我们每个人都会有身份证，身份证上面的身份证 码就是每个人的唯一标识。另外这个身份证 码会一直跟着我们不会改变，即使你改了名字户口状态变化，但是身份证 码是不会变化的，这也是实体的另一个特征就是它具有延续性。实体对应了业务对象的业务属性以及业务行为。

值对象以及实体都是领域模型中的领域对象，是组成领域模型的基础元素，一起实现领域内的最基本的核心领域逻辑。

聚合
又是一个看上去不好理解的概念，实际上用大白话来说，如果人是一个个不同的业务实体，那么 会中的不同组织、机构就是将对应技能的人聚集在一起发挥更大的业务价值以及完成更加复杂的业务行为的的集合。这就好比我们公司里面有种各样的部门，有人力部门负责招聘和薪酬、有销售部门负责营销、有研发部门负责产品研发。不同的部门实际就是不同的聚合。 聚合就是有业务关联关系的实体以及值对象的集合，通过实体、值对象以及各自之间的业务逻辑聚合在一起完成某个业务节点，我们就可以理解为聚合。我们可以根据业务的单一职责以及高内聚的的设计原来来进行聚合的划分。

聚合根
聚合的出现实际是一种业务单元，那它必定涉及到数据的持久化，如果在聚合中的任意实体都可以被外部进行数据修改，那么我们将很难保证聚合内的数据一致性。因此我们需要有一个数据输入修改的统一入口来保证聚合内的数据修改统一的符合聚合中的业务规则，因此出现了聚合根的概念。聚合根实际是就是一种实体，具备唯一标识，有独立的生命周期。但是他是特殊的实体，他有协调实体以及值对象完成业务逻辑的功能，好比是一个部门的负责人一样。一个聚合只有一个聚合根，聚合根在聚合之内采用引用依赖的方式对实体和值对象进行组织和协调，聚合根和聚合根之间通过唯一id进行聚合之间的协同。

战略设计

战略设计这四个字听起来有点高大上的感觉，感觉离我等DS比较远。实际上无论对于公司或者个人来说，都需要有个发展的目标以及指导方针，指引我们该向何方前进，这个指导性的内容，我们就可以称之为战略。那么在DDD领域，战略设计主要从业务角度出发，划分业务的领域边界，建立基于通用语言和业务上下文语义边界的限界上下文，实现业务领域模型的构建。使得限界上下文可以作为微服务拆分和设计的边界。因为必须先有边界清晰的领域模型以及上下文，我们才能设计出边界清晰的微服务。因此在战略设计阶段最重要的就是限界上下文以及领域建模。

通常在业务分析阶段我们把业务域的主体流程进行了梳理以及分析，同事将业务期望进行了定义。在进行战略设计的过程中，需要对业务领域进行全面的梳理，首先对业务进行领域切分，划分出业务的上下文边界，然后建立对应的限界上文中的领域模型，上下文边界和领域模型可以做诶微服务拆分拆分设计的输入，指导微服务落地时的拆分设计。其中业务中，对应的领域模型十分重要。那么我们该采用什么方法才能从复杂的业务领域中构建出高内聚低耦合的领域模型呢可以通过业务分析以及领域建模两个阶段来实现领域模型的构建。

业务分析

1、事件风暴
通过事件风暴的方法可以实现快速分析和分解复杂的业务领域，分析并提取出对应的领域模型。事件风暴是早2013年提出来的，通过组织领域专家、以及项目团队成员在一起通过头脑风暴的方式，通过梳理业务领域中所有的领域事件以及领域事件的参与者以及输入。
参与者
主要包括领域专家、DDD专家、架构师、产品经理、项目经理、开发人员以及测试人员等
实际活动
当把参与者集合在一起之后，大家需要通过头脑风暴的方式梳理当前的业务域问题。比如某个业务动作或者行为是否会触发下一个业务动作，这个动作（领域事件）的输入和输出是什么，是谁（实体）发出的什么动作（命令），触发了这个动作，这些我们都需要梳理清楚。

战术设计

不同于战略设计的高屋建瓴，战术设计是从实际的技术角度出发，它更加侧重于领域模型的技术实现，按照领域模型完成微服务的开发以及落地。从某种意义来说，战略设计实际就是战术设计的输入。在战术设计中会有聚合、聚合根、实体、值对象、领域服务、领域事件的代码实现，通过将这些领域对象映射到代码中实现设计以及系统的落地。在这个阶段，我们需要梳理微服务的边界以及边界内的领域对象以及它们之间的关系，并且可以实际的将这些领域模型确定在哪些代码模块中以及微服务分层中的具体位置。
通过DDD按照一定的规则对业务领域进行细分，是的问题范围可以限定在指定的边界中，因此我们可以在这个边界内建立领域模型，而后再通过代码实现领域模型，从而解决相应的业务问题。
因此在战术设计阶段，我们有个重要的事项需要去完成，一个是微服务的领域对象分析与边界划分，另一个是微服务的结构分层。

微服务领域对象分析与边界划分

在战略设计阶段，我们已经构建的业务领域模型，领域模型中包含了实体、值对象、聚合根。在上文中我们实际已经根据一些业务域进行了聚合的划分，那么在此处我们需要根据不同的聚合以及已有的限界上下文继续划分微服务。有的微服务会包含多个聚合，有的微服务只有一个聚合。

基础层：实际就是未微服务的其它层提供基础的通用技术支撑，如Redis、MQ以及数据库等，常见的就是数据库持久化可以放在这层当中。
用户接口层：负责向用户展示信息以及转化用户请求意图，在前后端分离的当下，可以实现在后端服务不变的情况下适配不同的用户前端的作用。
应用层：可以理解为实现领域对象以及多个聚合的服务编排以及组合，不应该有过多的业务逻辑。
领域层：领域层实际就是整个微服务的核心，在这其中涉及到领域对象的?状态变化以及领域规则。领域层主要包括实体、值对象、聚合根以及领域服务等。
当然实际上给还有其他的分层结构比如五层分层结构、六边形分层结构。

总结

文章知识点与官方知识档案匹配，可进一步学习相关知识Java技能树首页概览93627 人正在系统学习中