DDD实战课
2024-10-12 19:22:00 0 举报AI智能生成
DDD实战课是一门深入浅出、实践性强的课程，旨在帮助开发者掌握领域驱动设计（DDD）的核心概念和实践技巧。课程涵盖了领域建模、聚合设计、实体和值对象、领域事件、CQRS和事件溯源等关键知识点，并通过大量的实战案例帮助学员加深理解。无论你是刚接触DDD的新手，还是希望进一步巩固和提升技能的开发者，这门课程都能为你提供有价值的指导。通过这门课程，你将能够运用DDD的思想和方法，设计出更加清晰、可维护和可扩展的应用程序。
作者其他创作
大纲/内容
采用面向过程的设计方法，系统包括客户端 UI 层和数据库两层
采用 C/S 架构模式，整个系统围绕数据库驱动设计和开发，并且总是从设计数据库和字段开始。
第一阶段是单机架构
采用面向对象的设计方法，系统包括业务接入层、业务逻辑层和数据库层，采用经典的三层架构，也有部分应用采用传统的 SOA 架构。
这种架构容易使系统变得臃肿，可扩展性和弹性伸缩性差。
第二阶段是集中式架构
随着微服务架构理念的提出，集中式架构正向分布式微服务架构演进
微服务架构可以很好地实现应用之间的解耦，解决单体应用扩展性和弹性伸缩能力不足的问题。
第三阶段是分布式微服务架构
解释
在单机和集中式架构时代，系统分析、设计和开发往往是独立、分阶段割裂进行的。
A 负责提出需求，B 负责需求分析，C 负责系统设计，D 负责代码实现，这样的流程很长，经手的人也很多，很容易导致信息丢失
最后，就很容易导致需求、设计与代码实现的不一致，往往到了软件上线后
我们才发现很多功能并不是自己想要的，或者做出来的功能跟自己提出的需求偏差太大。
在系统建设过程中，我们经常会看到这样的情形
例子
在单机和集中式架构这两种模式下，软件无法快速响应需求和业务的迅速变化，最终错失发展良机
缺点
分布式微服务的出现就有点恰逢其时的意思了。
分析
软件架构模式的演进
微服务确实也解决了原来采用集中式架构的单体应用的很多问题
比如扩展性，弹性伸缩能力，小规模团队的敏捷开发等等
背景
微服务的粒度应该多大呀？
微服务倒地如何拆分和设计？
微服务的边界应该在哪里？
问题
微服务拆分困境产生的根本原因就是不知道业务或者微服务的边界到底在什么地方
根本原因
确定了业务边界和应用边界，这个困境也就迎刃而解了。
思路
DDD领域驱动设计
方法
微服务设计和拆分的困境
它试图分离技术实现的复杂性，并围绕业务概念构建领域模型来控制业务的复杂性
以解决软件难以理解，难以演进的问题
DDD 是一种处理高度复杂领域的设计思想
它通过边界划分将复杂业务领域简单化
帮我们设计出清晰的领域和应用边界，可以很容易地实现架构演进。
DDD 不是架构，而是一种架构设计方法论
DDD的解释
主要从业务视角出发，建立业务领域模型，划分领域边界
建立通用语言的限界上下文，限界上下文可以作为微服务设计的参考边界。
概念
通常采用用例分析、场景分析和用户旅程分析
尽可能全面不遗漏地分解业务领域，并梳理领域对象之间的关系，这是一个发散的过程
发散过程
事件风暴过程会产生很多的实体、命令、事件等领域对象，我们将这些领域对象从不同的维度进行聚类，形成如聚合
限界上下文等边界，建立领域模型，这就是一个收敛的过程。
收敛过程
事件风暴是建立领域模型的主要方法，它是一个从发散到收敛的过程。
在事件风暴中梳理业务过程中的用户操作、事件以及外部依赖关系等
根据这些要素梳理出领域实体等领域对象。
第一步：
根据领域实体之间的业务关联性，将业务紧密相关的实体进行组合形成聚合，同时确定聚合中的聚合根、值对象和实体
在这个图里，聚合之间的边界是第一层边界，它们在同一个微服务实例中运行，这个边界是逻辑边界，所以用虚线表示。
第二步：
根据业务及语义边界等因素，将一个或者多个聚合划定在一个限界上下文内，形成领域模型。
在这个图里，限界上下文之间的边界是第二层边界，这一层边界可能就是未来微服务的边界，不同限界上下文内的领域逻辑被隔离在不同的微服务实例中运行，物理上相互隔离，所以是物理边界，边界之间用实线来表示。
第三步：
用三步来划定领域模型和微服务的边界
领域模型的建立
DDD 战略设计会建立领域模型，领域模型可以用于指导微服务的设计和拆分
在战略设计中我们建立了领域模型，划定了业务领域的边界，建立了通用语言和限界上下文，确定了领域模型中各个领域对象的关系
到这儿，业务端领域模型的设计工作基本就完成了，这个过程同时也基本确定了应用端的微服务边界
现象
战略设计
则从技术视角出发，侧重于领域模型的技术实现，完成软件开发和落地
包括：聚合根、实体、值对象、领域服务、应用服务和资源库等代码逻辑的设计和实现。
在从业务模型向微服务落地的过程中，也就是从战略设计向战术设计的实施过程中
我们会将领域模型中的领域对象与代码模型中的代码对象建立映射关系，将业务架构和系统架构进行绑定。
当我们去响应业务变化调整业务架构和领域模型时，系统架构也会同时发生调整，并同步建立新的映射关系。
战略--》战术
战术设计
组成部分
为什么 DDD 适合微服务？
DDD 是一种架构设计方法，微服务是一种架构风格
两者从本质上都是为了追求高响应力，而从业务视角去分离应用系统建设复杂度的手段
两者都强调从业务出发，其核心要义是强调根据业务发展，合理划分领域边界，持续调整现有架构，优化现有代码，以保持架构和代码的生命力，也就是我们常说的演进式架构
共同点
从业务领域视角划分领域边界，构建通用语言进行高效沟通
通过业务抽象，建立领域模型，维持业务和代码的逻辑一致性。
DDD 主要关注
运行时的进程间通信、容错和故障隔离，实现去中心化数据管理和去中心化服务治理
关注微服务的独立开发、测试、构建和部署。
微服务主要关注
区别
DDD 与微服务的关系
00 开篇词 学好了DDD，你能做什么？
领域是从事一种专门活动或事业的范围、部类或部门
领域具体指一种特定的范围或区域
两个解释有一个共同点——范围
领域就是用来确定范围的，范围即边界，这也是DDD 在设计中不断强调边界的原因。
在研究和解决业务问题时，DDD 会按照一定的规则将业务领域进行细分，当领域细分到一定的程度后
DDD 会将问题范围限定在特定的边界内，在这个边界内建立领域模型，进而用代码实现该领域模型，解决相应的业务问题
简言之，DDD 的领域就是这个边界内要解决的业务问题域。
场景
既然领域是用来限定业务边界和范围的，那么就会有大小之分
领域越大，业务范围就越大，反之则相反
注意
领域
领域可以进一步划分为子领域
我们把划分出来的多个子领域称为子域，每个子域对应一个更小的问题域或更小的业务范围。
子域
DDD 是如何使业务从复杂变得简单，更容易让人理解，技术实现更容易呢？
DDD 的研究方法与自然科学的研究方法类似
当人们在自然科学研究中遇到复杂问题时，通常的做法就是将问题一步一步地细分，再针对细分出来的问题域，逐个深入研究，探索和建立所有子域的知识体系
当所有问题子域完成研究时，我们就建立了全部领域的完整知识体系了。
答案
确定研究对象，即研究领域，这里是一棵桃树
第一步
其中营养器官包括根、茎和叶，生殖器官包括花、果实和种子
对研究对象进行细分，将桃树细分为器官，器官又分为营养器官和生殖器官两种
根、茎、叶、花、果实和种子等器官则是细分后的问题子域。
桃树的知识体系是我们已经确定要研究的问题域，对应 DDD 的领域
这个过程就是 DDD 将领域细分为多个子域的过程
第二步
比如，叶子器官可细分为保护组织、营养组织和输导组织等
p class=\"p1\" style=\
这个过程就是 DDD 将子域进一步细分为多个子域的过程。
对组织进行细分，将组织细分为细胞，细胞成为我们研究的最小单元
第四步
我们知道细胞核、线粒体、细胞膜等物质共同构成细胞，这些物质一起协作让细胞具有这类细胞特定的生物功能
细胞内的这些物质就可以理解为聚合里面的聚合根、实体以及值对象等
在聚合内这些实体一起协作完成特定的业务功能
这个过程类似 DDD 设计时，确定微服务内功能要素和边界的过程。
类比
如图所示
如何理解领域和子域？
决定产品和公司核心竞争力的子域是核心域，它是业务成功的主要因素和公司的核心竞争力
核心域
没有太多个性化的诉求，同时被多个子域使用的通用功能子域是通用域
比如认证、权限等等，这类应用很容易买到，没有企业特点限制，不需要做太多的定制化
通用域则是你需要用到的通用系统
通用域
但既不包含决定产品和公司核心竞争力的功能，也不包含通用功能的子域
则具有企业特性，但不具有通用性
特点
例如数据代码类的数据字典等系统。
如何理解核心域、通用域和支撑域？
公司在 IT 系统建设过程中，由于预算和资源有限，对不同类型的子域应有不同的关注度和资源投入策略，记住好钢要用在刀刃上。
有的公司核心域可能在客户服务，有的可能在产品质量，有的可能在物流
在公司领域细分、建立领域模型和系统建设时，我们就要结合公司战略重点和商业模式，找到核心域了，且重点关注核心域。
商业模式的不同会导致核心域划分结果的不同
我建议你和你的技术团队要将核心域的建设排在首位，最好是有绝对的掌控能力和自主研发能力
如果资源实在有限的话，可以在支撑域或者通用域上想想办法，暂时采用外购的方式也未尝不可。
如果你的公司刚好有意向转型微服务架构的话
那为什么要划分核心域、通用域和支撑域，主要目的是什么呢？
02 | 领域、子域、核心域、通用域和支撑域：傻傻分不清？
通用语言定义上下文含义
限界上下文则定义领域边界
通用语言和限界上下文
在事件风暴过程中，通过团队交流达成共识的，能够简单、清晰、准确描述业务涵义和规则的语言就是通用语言
通用语言包含术语和用例场景，并且能够直接反映在代码中
通用语言中的名词可以给领域对象命名，如商品、订单等，对应实体对象
通用语言中的名词
通用语言中的动词
作为项目团队沟通和协商形成的统一语言，基于它，你就能够开发出可读性更好的代码，将业务需求准确转化为代码设计
作用
领域专家会和设计、开发人员一起建立领域模型，在领域建模的过程中会形成通用的业务术语和用户故事
事件风暴也是一个项目团队统一语言的过程。
1.在事件风暴的过程中
3. 微服务代码模型来源于领域模型，每个代码模型的代码对象跟领域对象一一对应。
从事件风暴建立通用语言到领域对象设计和代码落地的完整过程图
设计过程中我们可以用一些表格，来记录事件风暴和微服务设计过程中产生的领域对象及其属性
领域对象在 DDD 分层架构中的位置、属性、依赖关系以及与代码模型对象的映射关系等。
经验
在代码模型设计的时侯就要建立领域对象和代码对象的一一映射，从而保证业务模型和代码模型的一致，实现业务语言与代码语言的统一
什么是通用语言？
我们知道语言都有它的语义环境，同样，通用语言也有它的上下文环境
而上下文则是语义环境
通过领域的限界上下文，我们就可以在统一的领域边界内用统一的语言进行交流。
限界和上下文
用来封装通用语言和领域对象，提供上下文环境，保证在领域之内的一些术语、业务相关对象等（通用语言）有一个确切的含义，没有二义性
这个边界定义了模型的适用范围，使团队所有成员能够明确地知道什么应该在模型中实现，什么不应该在模型中实现。
领域边界就是通过限界上下文来定义的
总结
什么是限界上下文？
一个领域相当于一个问题域，领域拆分为子域的过程就是大问题拆分为小问题的过程
在这个图里面保险领域被拆分为：投保、支付、保单管理和理赔四个子域。
首先，领域可以拆分为多个子领域
比如，支付子域可继续拆分为收款和付款子子域
拆到一定程度后，有些子子域的领域边界就可能变成限界上下文的边界了。
子域还可根据需要进一步拆分为子子域
如理赔子域就包括报案、查勘和定损等多个限界上下文（限界上下文与理赔的子子域领域边界重合）
也有可能子域本身的边界就是限界上下文边界，如投保子域
子域可能会包含多个限界上下文
每个领域模型都有它对应的限界上下文，团队在限界上下文内用通用语言交流
保险模型
理论上限界上下文就是微服务的边界
我们将限界上下文内的领域模型映射到微服务，就完成了从问题域到软件的解决方案。
可以说，限界上下文是微服务设计和拆分的主要依据
在领域模型中，如果不考虑技术异构、团队沟通等其它外部因素，一个限界上下文理论上就可以设计为一个微服务
限界上下文和微服务的关系
03 | 限界上下文：定义领域边界的利器
在 DDD 中有这样一类对象，它们拥有唯一标识符，且标识符在历经各种状态变更后仍能保持一致
对这些对象而言，重要的不是其属性，而是其延续性和标识，对象的延续性和标识会跨越甚至超出软件的生命周期
在 DDD 不同的设计过程中，实体的形态是不同的
在战略设计时，实体是领域模型的一个重要对象。领域模型中的实体是多个属性、操作或行为的载体
实体和值对象是组成领域模型的基础单元。
1. 实体的业务形态
在代码模型中，实体的表现形式是实体类，这个类包含了实体的属性和方法，通过这些方法实现实体自身的业务逻辑
在 DDD 里，这些实体类通常采用充血模型
2. 实体的代码形态
实体以 DO（领域对象）的形式存在，每个实体对象都有唯一的 ID
我们可以对一个实体对象进行多次修改，修改后的数据和原来的数据可能会大不相同
比如商品是商品上下文的一个实体，通过唯一的商品 ID 来标识，不管这个商品的数据如何变化
商品的 ID 一直保持不变，它始终是同一个商品。
但是，由于它们拥有相同的 ID，它们依然是同一个实体
3. 实体的运行形态
与传统数据模型设计优先不同，DDD 是先构建领域模型
针对实际业务场景构建实体对象和行为，再将实体对象映射到数据持久化对象。
在领域模型映射到数据模型时，一个实体可能对应 0 个、1 个或者多个数据库持久化对象
大多数情况下实体与持久化对象是一对一
在某些场景中，有些实体只是暂驻静态内存的一个运行态实体，它不需要持久化
介绍
4. 实体的数据库形态
实体
通过对象属性值来识别的对象，它将多个相关属性组合为一个概念整体
在 DDD 中用来描述领域的特定方面，并且是一个没有标识符的对象，叫作值对象。
定义
值对象描述了领域中的一件东西，这个东西是不可变的，它将不同的相关属性组合成了一个概念整体
值对象本质上就是一个集和
若干个用于描述目的、具有整体概念和不可修改的属性
这个集合里面有什么
在领域建模的过程中，值对象可以保证属性归类的清晰和概念的完整性，避免属性零碎
这个集合的意义又是什么
人员实体原本包括：姓名、年龄、性别以及人员所在的省、市、县和街道等属性
这样显示地址相关的属性就很零碎了对不对
现在，我们可以将“省、市、县和街道等属性”拿出来构成一个“地址属性集合”，这个集合就是值对象了。
本质
它跟实体一样都来源于事件风暴所构建的领域模型，都包含了若干个属性，它与实体一起构成聚合
本质上，实体是看得到、摸得着的实实在在的业务对象，实体具有业务属性、业务行为和业务逻辑
而值对象只是若干个属性的集合，只有数据初始化操作和有限的不涉及修改数据的行为，基本不包含业务逻辑。
值对象的属性集虽然在物理上独立出来了，但在逻辑上它仍然是实体属性的一部分，用于描述实体的特征。
对照实体来看
在值对象中也有部分共享的标准类型的值对象，它们有自己的限界上下文
有自己的持久化对象，可以建立共享的数据类微服务，比如数据字典。
1. 值对象的业务形态
如果值对象是属性集合，则把它设计为 Class 类，Class 将具有整体概念的多个属性归集到属性集合，这样的值对象没有 ID，会被实体整体引用。
值对象在代码中有这样两种形态
引用单一属性的值对象或只有一条记录的多属性值对象的实体，可以采用属性嵌入的方式嵌入。
属性嵌入的方式
引用一条或多条记录的多属性值对象的实体，可以采用序列化大对象的方式嵌入
序列化大对象的方式
值对象嵌入到实体的话，有这样两种不同的数据格式，也可以说是两种方式
3. 值对象的运行形态
DDD 引入值对象是希望实现从“数据建模为中心”向“领域建模为中心”转变
减少数据库表的数量和表与表之间复杂的依赖关系，尽可能地简化数据库设计，提升数据库性能
如何理解用值对象来简化数据库设计呢？
传统的数据建模大多是根据数据库范式设计的，每一个数据库表对应一个实体，每一个实体的属性值用单独的一列来存储，一个实体主表会对应 N 个实体从表
把地址值对象的所有属性都放到人员实体表中，创建人员实体，创建人员数据表
第一个方案会破坏地址的业务涵义和概念完整
方案一
创建人员和地址两个实体，同时创建人员和地址两张表。
第二个方案增加了不必要的实体和表，需要处理多个实体和表的关系，从而增加了数据库设计的复杂性。
方案二
基于上述人员和地址那个场景，实体和数据模型设计通常有两种解决方案
而在数据建模时，我们可以将地址的属性值嵌入人员实体数据库表中，只创建人员数据库表
这样既可以兼顾业务含义和表达，又不增加数据库的复杂度
优化方法
在领域建模时，我们可以将部分对象设计为值对象，保留对象的业务涵义，同时又减少了实体的数量
在数据建模时，我们可以将值对象嵌入实体，减少实体表的数量，简化数据库设计。
也有 DDD 专家认为，要想发挥对象的威力，就需要优先做领域建模，弱化数据库的作用，只把数据库作为一个保存数据的仓库即可
即使违反数据库设计原则，也不用大惊小怪，只要业务能够顺利运行，就没什么关系。
扩展
4. 值对象的数据库形态
但如果实体引用的值对象过多，则会导致实体堆积一堆缺乏概念完整性的属性
这样值对象就会失去业务涵义，操作起来也不方便。
值对象采用属性嵌入的方法提升了数据库的性能
这种设计方式虽然降低了数据库设计的复杂度
却无法满足基于值对象的快速查询，会导致搜索值对象属性值变得异常困难。
采用序列化大对象的方法简化了数据库设计，减少了实体表的数量，可以简单、清晰地表达业务概念
优势
5. 值对象的优势和局限
值对象
实体和值对象是微服务底层的最基础的对象，一起实现实体最基本的核心领域逻辑。
DDD 提倡从领域模型设计出发，而不是先设计数据模型
传统的数据模型设计通常是一个表对应一个实体，一个主表关联多个从表，当实体表太多的时候就很容易陷入无穷无尽的复杂的数据库设计，领域模型就很容易被数据模型绑架
可以说，值对象的诞生，在一定程度上，和实体是互补的。
人员是实体，地址是值对象，地址值对象被人员实体引用
在领域模型
地址值对象可以作为一个属性集整体嵌入人员实体中，组合形成上图这样的数据模型；
也可以以序列化大对象的形式加入到人员的地址属性中，前面表格有展示。
数据库模型中
实体和值对象的关系
同样的对象在不同的场景下，可能会设计出不同的结果
有些场景中，地址会被某一实体引用，它只承担描述实体的作用，并且它的值只能整体替换，这时候你就可以将地址设计为值对象，比如收货地址
而在某些业务场景中，地址会被经常修改，地址是作为一个独立对象存在的，这时候它应该设计为实体，比如行政区划中的地址信息维护。
04 | 实体和值对象：从领域模型的基础单元看系统设计
在事件风暴中，我们会根据一些业务操作和行为找出实体（Entity）或值对象（ValueObject）
进而将业务关联紧密的实体和值对象进行组合，构成聚合
再根据业务语义将多个聚合划定到同一个限界上下文（Bounded Context）中，并在限界上下文内完成领域建模。
在 DDD 中，实体和值对象是很基础的领域对象
实体一般对应业务对象，它具有业务属性和业务行为
而值对象主要是属性集合，对实体的状态和特征进行描述。
那聚合在其中起什么作用呢？
随着社会的发展，慢慢出现了社团、机构、部门等组织，我们开始从个人变成了组织的一员
大家可以协同一致的工作，朝着一个最大的目标前进，发挥出更大的力量
领域模型内的实体和值对象就好比个体，而能让实体和值对象协同工作的组织就是聚合
它用来确保这些领域对象在实现共同的业务逻辑时，能保证数据的一致性
解释一
聚合就是由业务和逻辑紧密关联的实体和值对象组合而成的
聚合是数据修改和持久化的基本单元，每一个聚合对应一个仓储，实现数据的持久化。
解释二
聚合有一个聚合根和上下文边界，这个边界根据业务单一职责和高内聚原则，定义了聚合内部应该包含哪些实体和值对象，而聚合之间的边界是松耦合的
按照这种方式设计出来的微服务很自然就是“高内聚、低耦合”的。
聚合在 DDD 分层架构里属于领域层，领域层包含了多个聚合，共同实现核心业务逻辑
位置
聚合内实体以充血模型实现个体业务能力，以及业务逻辑的高内聚
跨多个实体的业务逻辑通过领域服务来实现，跨多个聚合的业务逻辑通过应用服务来实现
比如有的业务场景需要同一个聚合的 A 和 B 两个实体来共同完成，我们就可以将这段业务逻辑用领域服务来实现；
而有的业务逻辑需要聚合 C 和聚合 D 中的两个服务共同完成，这时你就可以用应用服务来组合这两个服务
实现方式
聚合
是为了避免由于复杂数据模型缺少统一的业务规则控制，而导致聚合、实体之间数据不一致性的问题。
目的
每一个实体都是对等的，如果任由实体进行无控制地调用和数据修改，很可能会导致实体之间数据逻辑的不一致
而如果采用锁的方式则会增加软件的复杂度，也会降低系统的性能。
传统数据模型
如果把聚合比作组织，那聚合根就是这个组织的负责人
聚合根也称为根实体，它不仅是实体，还是聚合的管理者。
首先它作为实体本身，拥有实体的属性和业务行为，实现自身的业务逻辑。
其次它作为聚合的管理者，在聚合内部负责协调实体和值对象按照固定的业务规则协同完成共同的业务逻辑。
聚合之间通过聚合根 ID 关联引用，如果需要访问其它聚合的实体，就要先访问聚合根
再导航到聚合内部实体，外部对象不能直接访问聚合内实体。
最后在聚合之间，它还是聚合对外的接口人，以聚合根 ID 关联的方式接受外部任务和请求，在上下文内实现聚合之间的业务协同
聚合根
DDD 领域建模通常采用事件风暴，它通常采用用例分析、场景分析和用户旅程分析等方法，通过头脑风暴列出所有可能的业务行为和事件
然后找出产生这些行为的领域对象，并梳理领域对象之间的关系，找出聚合根
找出与聚合根业务紧密关联的实体和值对象
再将聚合根、实体和值对象组合，构建聚合。
查找聚合根的过程
采用事件风暴，根据业务行为，梳理出在投保过程中发生这些行为的所有的实体和值对象
比如投保单、标的、客户、被保人等等。
从众多实体中选出适合作为对象管理者的根实体，也就是聚合根
是否有独立的生命周期？
是否有全局唯一 ID？
是否可以创建或修改其它对象
是否有专门的模块来管这个实体。
判断一个实体是否是聚合根，你可以结合以下场景分析
图中的聚合根分别是投保单和客户实体。
根据业务单一职责和高内聚原则，找出与聚合根关联的所有紧密依赖的实体和值对象
构建出 1 个包含聚合根（唯一）、多个实体和值对象的对象集合，这个集合就是聚合
在图中我们构建了客户和投保这两个聚合
第三步
在聚合内根据聚合根、实体和值对象的依赖关系，画出对象的引用和依赖模型
投保人和被保人的数据，是通过关联客户 ID 从客户聚合中获取的
在投保聚合里它们是投保单的值对象，这些值对象的数据是客户的冗余数据
即使未来客户聚合的数据发生了变更，也不会影响投保单的值对象数据
这里我需要说明一下
比如在投保聚合里投保单聚合根引用了报价单实体，报价单实体则引用了报价规则子实体。
从图中我们还可以看出实体之间的引用关系
多个聚合根据业务语义和上下文一起划分到同一个限界上下文内
第五步
步骤解释
看一下聚合的构建过程主要都包括哪些步骤。
怎样设计聚合？
聚合用来封装真正的不变性，而不是简单地将对象组合在一起
聚合内有一套不变的业务规则，各实体和值对象按照统一的业务规则运行，实现对象数据的一致性，边界之外的任何东西都与该聚合无关，这就是聚合能实现业务高内聚的原因。
1. 在一致性边界内建模真正的不变条件
如果聚合设计得过大，聚合会因为包含过多的实体，导致实体之间的管理过于复杂
高频操作时会出现并发冲突或者数据库锁，最终导致系统可用性变差
聚合设计过大问题
可以降低由于业务过大导致聚合重构的可能性，让领域模型更能适应业务的变化。
小聚合解决
2. 设计小聚合
聚合之间是通过关联外部聚合根 ID 的方式引用，而不是直接对象引用的方式
外部聚合的对象放在聚合边界内管理，容易导致聚合的边界不清晰，也会增加聚合之间的耦合度
3. 通过唯一标识引用其它聚合
聚合内数据强一致性，而聚合之间数据最终一致性
在一次事务中，最多只能更改一个聚合的状态。
如果一次业务操作涉及多个聚合状态的更改，应采用领域事件的方式异步修改相关的聚合，实现聚合之间的解耦
涉及多个聚合状态的修改方法
4. 在边界之外使用最终一致性
为实现微服务内聚合之间的解耦，以及未来以聚合为单位的微服务组合和拆分
应避免跨聚合的领域服务调用和跨聚合的数据库表关联
5. 通过应用层实现跨聚合的服务调用
聚合的一些设计原则
05 | 聚合和聚合根：怎样设计聚合
在事件风暴（Event Storming）时，我们发现除了命令和操作等业务行为以外
还有一种非常重要的事件，这种事件发生后通常会导致进一步的业务操作，在 DDD 中这种事件被称为领域事件。
领域事件是领域模型中非常重要的一部分，用来表示领域中发生的事件
一个领域事件将导致进一步的业务操作，在实现业务解耦的同时，还有助于形成完整的业务闭环。
领域事件可以是业务流程的一个步骤
也可能是定时批处理过程中发生的事件，比如批处理生成季缴保费通知单，触发发送缴费邮件通知操作；
或者一个事件发生后触发的后续动作，比如密码连续输错三次，触发锁定账户的动作。
“如果发生……，则……”
“当做完……的时候，请通知……”
“发生……时，则……”等
在这些场景中，如果发生某种事件后，会触发进一步的操作，那么这个事件很可能就是领域事件。
在做用户旅程或者场景分析时，我们要捕捉业务、需求人员或领域专家口中的关键词
领域事件驱动设计可以切断领域模型之间的强依赖关系，事件发布完成后
发布方不必关心后续订阅方事件处理是否成功，这样可以实现领域模型的解耦，维护领域模型的独立性和数据的一致性
在领域模型映射到微服务系统架构时，领域事件可以解耦微服务，微服务之间的数据不必要求强一致性，而是基于事件的最终一致性。
优点
有的领域事件发生在微服务内的聚合之间
有的则发生在微服务之间，还有两者皆有的场景，一般来说跨微服务的领域事件处理居多
在微服务设计时不同领域事件的处理方式会不一样。
当领域事件发生在微服务内的聚合之间，领域事件发生后完成事件实体构建和事件数据持久化
发布方聚合将事件发布到事件总线，订阅方接收事件数据完成后续业务操作。
流程
但一个事件如果同时更新多个聚合，按照 DDD“一次事务只更新一个聚合”的原则，你就要考虑是否引入事件总线
但微服务内的事件总线，可能会增加开发的复杂度，因此你需要结合应用复杂度和收益进行综合考虑
微服务内大部分事件的集成，都发生在同一个进程内，进程自身可以很好地控制事务，因此不一定需要引入消息中间件
方式一
微服务内应用服务，可以通过跨聚合的服务编排和组合，以服务调用的方式完成跨聚合的访问
这种方式通常应用于实时性和数据一致性要求高的场景
这个过程会用到分布式事务，以保证发布方和订阅方的数据同时更新成功。
方式二
实现逻辑
1. 微服务内的领域事件
跨微服务的领域事件会在不同的限界上下文或领域模型之间实现业务协作
其主要目的是实现微服务解耦，减轻微服务之间实时服务访问的压力。
跨微服务的事件可以推动业务流程或者数据在不同的子域或微服务间直接流转。
跨微服务的事件机制要总体考虑事件构建、发布和订阅、事件数据持久化、消息中间件
甚至事件数据持久化时还可能需要考虑引入分布式事务机制等
实现方式一
微服务之间的访问也可以采用应用服务直接调用的方式，实现数据和服务的实时访问
弊端就是跨微服务的数据同时变更需要引入分布式事务，以确保数据的一致性。
分布式事务机制会影响系统性能，增加微服务之间的耦合，所以我们还是要尽量避免使用分布式事务
实现方式二
2. 微服务之间的领域事件
具体场景下的领域事件
发生的场景
那如何识别领域事件呢？
领域事件
这个过程会产生很多的领域事件，这些领域事件促成了保险业务数据、对象在不同的微服务和子域之间的流转和角色转换。
客户购买保险 - 业务人员完成保单录入 - 生成投保单 - 启动缴费动作。
事件起点
缴费通知单已生成，将缴费通知单数据发布到消息中间件
收款微服务订阅缴费通知单事件，完成缴费操作
缴费通知单已生成，领域事件结束。
1. 投保微服务生成缴费通知单，发布第一个事件
缴费已完成，将缴费数据发布到消息中间件
原来的订阅方收款微服务这时则变成了发布方。原来的事件发布方投保微服务转换为订阅方
投保微服务在收到缴费信息并确认缴费完成后，完成投保单转成保单的操作。缴费已完成，领域事件结束。
2. 收款微服务缴费完成后，发布第二个领域事件
保单微服务接收到保单数据后，完成保单数据保存操作。保单已生成，领域事件结束。
3. 投保微服务在投保单转保单完成后，发布第三个领域事件
以并发的方式将保单数据通过消息中间件发送到佣金、收付费和再保等微服务
一直到财务，完后保单后续所有业务流程
4. 保单微服务完成保单数据保存后，后面还会发生一系列的领域事件
通过领域事件驱动的异步化机制，可以推动业务流程和数据在各个不同微服务之间的流转
实现微服务的解耦，减轻微服务之间服务调用的压力，提升用户体验。
一个保险承保业务过程中有关领域事件的案例。
领域事件相关案例
领域事件的执行需要一系列的组件和技术来支撑
其中事件唯一标识应该是全局唯一的，以便事件能够无歧义地在多个限界上下文中传递
发生时间
事件类型和事件源
事件基本属性主要记录事件自身以及事件发生背景的数据。
事件基本属性至少包括
用于记录事件发生那一刻的业务数据，这些数据会随事件传输到订阅方，以开展下一步的业务操作。
事件业务属性
事件基本属性和业务属性一起构成事件实体，事件实体依赖聚合根
领域事件发生后，事件中的业务数据不再修改，因此业务数据可以以序列化值对象的形式保存，这种存储格式在消息中间件中也比较容易解析和获取
由于事件没有太多的业务行为，实现方法一般比较简单
事件发布之前需要先构建事件实体并持久化
可以通过应用服务
或者消息中间件
也可以从事件表中利用定时程序或数据库日志捕获技术获取增量事件数据，发布到消息中间件。
事件发布的方式有很多种
具体代码如下
1. 事件构建和发布
事件数据持久化可用于系统之间的数据对账，或者实现发布方和订阅方事件数据的审计
当遇到消息中间件、订阅方系统宕机或者网络中断，在问题解决后仍可继续后续业务流转，保证数据的一致性。
持久化到本地业务数据库的事件表中，利用本地事务保证业务和事件数据的一致性。
持久化到共享的事件数据库中
业务数据库和事件数据库不在一个数据库中，它们的数据持久化操作会跨数据库
因此需要分布式事务机制来保证业务和事件数据的强一致性，结果就是会对系统性能造成一定的影响。
事件数据持久化有两种方案
2. 事件数据持久化
事件总线是实现微服务内聚合之间领域事件的重要组件，它提供事件分发和接收等服务。
事件总线是进程内模型，它会在微服务内聚合之间遍历订阅者列表，采取同步或异步的模式传递数据
如果是微服务内的订阅者（其它聚合），则直接分发到指定订阅者；
如果是微服务外的订阅者，将事件数据保存到事件库（表）并异步发送到消息中间件；
如果同时存在微服务内和外订阅者，则先分发到内部订阅者，将事件消息保存到事件库（表），再异步发送到消息中间件。
分发流程
3. 事件总线 (EventBus)
跨微服务的领域事件大多会用到消息中间件，实现跨微服务的事件发布和订阅
消息中间件的产品非常成熟，市场上可选的技术也非常多，比如 Kafka，RabbitMQ 等
4. 消息中间件
微服务订阅方在应用层采用监听机制，接收消息队列中的事件数据，完成事件数据的持久化后，就可以开始进一步的业务处理
领域事件处理可在领域服务中实现。
5. 事件接收和处理
领域事件总体技术架构图
领域事件总体架构
这里我用承保业务流程的缴费通知单事件，来给你解释一下领域事件的运行机制
这个领域事件发生在投保和收款微服务之间。发生的领域事件是：缴费通知单已生成
下一步的业务操作是：缴费。
事件起点：出单员生成投保单，核保通过后，发起生成缴费通知单的操作。
分别创建缴费通知单、缴费通知单事件。
其中缴费通知单事件类 PaymentNoticeEvent 继承基类 DomainEvent。
1. 投保微服务应用服务，调用聚合中的领域服务 createPaymentNotice 和createPaymentNoticeEvent
为了避免分布式事务，这些业务和事件数据都持久化到本地投保微服务数据库中。
2. 利用仓储服务持久化缴费通知单相关的业务和事件数据。
这里说明：事件发布也可以通过应用服务或者领域服务完成发布
3. 通过数据库日志捕获技术或者定时程序，从数据库事件表中获取事件增量数据，发布到消息中间件
监听并获取事件数据后，应用服务调用领域层的领域服务将事件数据持久化到本地数据库中。
4. 收款微服务在应用层从消息中间件订阅缴费通知单事件消息主题，
5. 收款微服务调用领域层的领域服务 PayPremium，完成缴费。
6. 事件结束。
步骤
领域事件运行机制相关案例
06 | 领域事件：解耦微服务的关键
整洁架构
CQRS
六边形架构等等
每种架构模式虽然提出的时代和背景不同，但其核心理念都是为了设计出“高内聚低耦合”的架构，轻松实现架构演进
而 DDD 分层架构的出现，使架构边界变得越来越清晰，它在微服务架构模型中，占有非常重要的位置。
微服务架构模型
DDD 的分层架构在不断发展。最早是传统的四层架构；
后来四层架构有了进一步的优化，实现了各层对基础层的解耦
再后来领域层和应用层之间增加了上下文环境（Context）层，五层架构（DCI）就此形成了。
演化之路
基础层是被其它层依赖的，它位于最核心的位置，那按照分层架构的思想，
它应该就是核心，但实际上领域层才是软件的核心，所以这种依赖是有问题的
在最早的传统四层架构中
用户接口层负责向用户显示信息和解释用户指令。
这里的用户可能是：用户、程序、自动化测试和批处理脚本等等。
用户接口层
应用层是很薄的一层，理论上不应该有业务规则或逻辑，主要面向用例和流程相关的操作。
因为领域层包含多个聚合，所以它可以协调多个聚合的服务和领域对象完成服务编排和组合，协作完成业务操作。
但应用层又位于领域层之上
应用层也是微服务之间交互的通道，它可以调用其它微服务的应用服务，完成微服务之间的服务组合和编排
在设计和开发时，不要将本该放在领域层的业务逻辑放到应用层中实现
因为庞大的应用层会使领域模型失焦，时间一长你的微服务就会演化为传统的三层架构，业务逻辑会变得混乱
应用服务是在应用层的，它负责服务的组合、编排和转发，负责处理业务用例的执行顺序以及结果的拼装，以粗粒度的服务通过 API 网关向前端发布。
还有，应用服务还可以进行安全认证、权限校验、事务控制、发送或订阅领域事件等。
应用层
是实现企业核心业务逻辑，通过各种校验手段保证业务的正确性。
领域层主要体现领域模型的业务能力，它用来表达业务概念、业务状态和业务规则。
包含聚合根、实体、值对象、领域服务等领域模型中的领域对象。
组合
首先，领域模型的业务逻辑主要是由实体和领域服务来实现的，其中实体会采用充血模型来实现所有与之相关的业务功能
当领域中的某些功能，单一实体（或者值对象）不能实现时，领域服务就会出马
它可以组合聚合内的多个实体（或者值对象），实现复杂的业务逻辑。
其次，你要知道，实体和领域对象在实现业务逻辑上不是同级的
几个领域对象的关系
领域层
基础层是贯穿所有层的
就是为其它各层提供通用的技术和基础服务
包括第三方工具、驱动、消息中间件、网关、文件、缓存以及数据库等。
比较常见的功能还是提供数据库持久化。
基础层包含基础服务，它采用依赖倒置设计，封装基础资源服务，实现应用层、领域层与基础层的解耦，降低外部资源变化对应用的影响。
基础层
今天讲的是优化后的四层架构
什么是 DDD 分层架构？
每层只能与位于其下方的层发生耦合。
DDD 分层架构有一个重要的原则
优化后的DDD 分层架构模型就属于严格分层架构，任何层只能对位于其直接下方的层产生依赖。
严格分层架构
而传统的 DDD 分层架构则属于松散分层架构，它允许某层与其任意下方的层发生依赖。
松散分层架构。
建议你采用严格分层架构。
领域服务只能被应用服务调用，而应用服务只能被用户接口层调用，服务是逐层对外封装或组合的，依赖关系清晰
在严格分层架构中
领域服务可以同时被应用层或用户接口层调用，服务的依赖关系比较复杂且难管理，甚至容易使核心业务逻辑外泄。
松散分层架构中
试想下，如果领域层中的某个服务发生了重大变更，那该如何通知所有调用方同步调整和升级呢？但在严格分层架构中，你只需要逐层通知上层服务就可以了。
原因
如何选择
而架构根据耦合的紧密程度又可以分为两种：
DDD 分层架构最重要的原则是什么？
领域模型不是一成不变的，因为业务的变化会影响领域模型，而领域模型的变化则会影响微服务的功能和边界。
领域模型中对象的层次从内到外依次是：值对象、实体、聚合和限界上下文。
实体或值对象的简单变更，一般不会让领域模型和微服务发生大的变化。
这是因为聚合内业务功能内聚，能独立完成特定的业务逻辑。
那聚合的重组或拆分，势必就会引起业务模块和系统功能的变化了。
但聚合的重组或拆分却可以。
这里我们可以以聚合为基础单元，完成领域模型和微服务架构的演进。
聚合可以作为一个整体，在不同的领域模型之间重组或者拆分，或者直接将一个聚合独立为微服务。
出发点
我们可以把聚合 a 的代码，从微服务 1 中剥离出来，独立为微服务 2。
这样微服务 2 就可轻松应对高性能场景。
当你发现微服务 1 中聚合 a 的功能经常被高频访问，以致拖累整个微服务 1 的性能时
这时你就可以将聚合 d 的代码整体搬迁到微服务 1 中
如果你在设计时已经定义好了聚合之间的代码边界，这个过程不会太复杂，也不会花太多时间。
在业务发展到一定程度以后，你会发现微服务 2 的领域模型有了变化，聚合 d 会更适合放到微服务 1 的领域模型中
演进为包含聚合 b、c、d 的新领域模型和微服务了。
最后我们发现，在经历模型和架构演进后，微服务 1 已经从最初包含聚合 a、b、c
好的聚合和代码模型的边界设计，可以让你快速应对业务变化，轻松实现领域模型和微服务架构的演进。
你可能还会想，那怎么实现聚合代码快速重组呢
1.微服务架构的演进
在微服务内部，实体的方法被领域服务组合和封装，领域服务又被应用服务组合和封装
在服务逐层组合和封装的过程中，你会发现这样一个有趣的现象。
在服务设计时，你并不一定能完整预测有哪些下层服务会被多少个上层服务组装，因此领域层通常只提供一些原子服务，比如领域服务 a、b、c。
但随着系统功能增强和外部接入越来越多，应用服务会不断丰富
有一天你会发现领域服务 b 和 c 同时多次被多个应用服务调用了，执行顺序也基本一致
这时你可以考虑将 b 和 c 合并，再将应用服务中 b、c 的功能下沉到领域层，演进为新的领域服务（b+c）
这样既减少了服务的数量，也减轻了上层服务组合和编排的复杂度。
这就是服务演进的过程，它是随着你的系统发展的，最后你会发现你的领域模型会越来越精炼，越来越能适应需求的快速变化。
2.微服务内服务的演进
三层架构如何演进到 DDD 分层架构？
可以说，DDD 成功地降低了层与层之间的依赖。
首先，由于层间松耦合，我们可以专注于本层的设计，而不必关心其它层，也不必担心自己的设计会影响其它层。
我们修改某层代码时，只要本层的接口参数不变，其它层可以不必修改
即使本层的接口发生变化，也只影响相邻的上层，修改工作量小且错误可以控制，不会带来意外的风险。
其次，分层架构使得程序结构变得清晰，升级和维护更加容易。
传统企业应用大多是单体架构，而单体架构则大多是三层架构。
三层架构解决了程序内代码间调用复杂、代码职责不清的问题，但这种分层是逻辑概念
在物理上它是中心化的集中式架构，并不适合分布式微服务架构。
DDD 分层架构在用户接口层引入了 DTO，给前端提供了更多的可使用数据和更高的展示灵活性。
DDD 分层架构将业务逻辑层的服务拆分到了应用层和领域层
应用层快速响应前端的变化，领域层实现领域模型的能力
DDD 分层架构对三层架构的业务逻辑层进行了更清晰的划分，改善了三层架构核心业务逻辑混乱，代码改动相互影响大的情况
三层架构数据访问采用 DAO 方式；
DDD 分层架构的数据库等基础资源访问，采用了仓储（Repository）设计模式，通过依赖倒置实现各层对基础资源的解耦。
仓储接口放在领域层中
仓储接口
仓储实现放在基础层。
仓储实现
仓储又分为两部分
原来三层架构通用的第三方工具包、驱动、Common、Utility、Config 等通用的公共的资源类统一放到了基础层。
另外一个重要的变化发生在数据访问层和基础层之间。
首先，你要清楚，三层架构向 DDD 分层架构演进，主要发生在业务逻辑层和数据访问层。
最后，我想说，传统三层架构向 DDD 分层架构的演进，体现的正是领域驱动设计思想的演进。希望你也感受到了，并尝试将其应用在自己的架构设计中。
转化过程
那我们该怎样转向 DDD 分层架构呢？不妨看看下面这个过程。
07 | DDD分层架构：有效降低层与层之间的依赖
整洁架构又名“洋葱架构”。为什么叫它洋葱架构？看看下面这张图你就明白了
整洁架构的层就像洋葱片一样，它体现了分层的设计思想。
在整洁架构里，同心圆代表应用软件的不同部分，从里到外依次是领域模型、领域服务、应用服务和最外围的容易变化的内容，比如用户界面和基础设施
它定义了各层的依赖关系，越往里依赖越低，代码级别越高，越是核心能力。
外圆代码依赖只能指向内圆，内圆不需要知道外圆的任何情况。
整洁架构最主要的原则是依赖原则
领域模型实现领域内核心业务逻辑，它封装了企业级的业务规则
领域模型的主体是实体，一个实体可以是一个带方法的对象，也可以是一个数据结构和方法集合。
领域服务实现涉及多个实体的复杂业务逻辑。
应用服务实现与用户操作相关的服务组合与编排，它包含了应用特有的业务流程规则，封装和实现了系统所有用例。
主动适配主要实现外部用户、网页、批处理和自动化测试等对内层业务逻辑访问适配。
被动适配主要是实现核心业务逻辑对基础资源访问的适配，比如数据库、缓存、文件系统和消息中间件等。
最外层主要提供适配的能力，适配能力分为主动适配和被动适配。
红圈内的领域模型、领域服务和应用服务一起组成软件核心业务能力。
各层的职能划分
六边形架构又名“端口适配器架构”。追溯微服务架构的渊源，一般都会涉及到六边形架构。
应用是通过端口与外部进行交互的。我想这也是微服务架构下API 网关盛行的主要原因吧。
核心理念
在下图的六边形架构中，红圈内的核心业务逻辑（应用程序和领域模型）与外部资源（包括 APP、Web 应用以及数据库资源等）完全隔离，仅通过适配器进行交互。
它解决了业务逻辑与用户界面的代码交错问题，很好地实现了前后端分离。
六边形架构各层的依赖关系与整洁架构一样，都是由外向内依赖。
红圈内的六边形实现应用的核心业务逻辑；
外六边形完成外部应用、驱动和基础资源等的交互和访问，对前端应用以 API 主动适配的方式提供服务，对基础资源以依赖倒置被动适配的方式实现资源访问。
六边形架构将系统分为内六边形和外六边形两层，这两层的职能划分如下：
六边形架构的一个端口可能对应多个外部系统，不同的外部系统也可能会使用不同的适配器，由适配器负责协议转换
这就使得应用程序能够以一致的方式被用户、程序、自动化测试和批处理脚本使用。
子主题
六边形架构
虽然 DDD 分层架构、整洁架构、六边形架构的架构模型表现形式不一样，但你不要被它们的表象所迷惑
这三种架构模型的设计思想正是微服务架构高内聚低耦合原则的完美体现，而它们身上闪耀的正是以领域模型为中心的设计思想
它的作用就是将核心业务逻辑与外部应用、基础资源进行隔离。
有的业务逻辑属于领域模型的能力
有的则属于面向用户的用例和流程编排能力
按照这种功能的差异，我们在这种架构中划分了应用层和领域层，来承担不同的业务逻辑。
红色框内部主要实现核心业务逻辑，但核心业务逻辑也是有差异的
红色框部分，三种架构都有
领域层实现面向领域模型，实现领域模型的核心业务逻辑，属于原子模型，它需要保持领域模型和业务逻辑的稳定，对外提供稳定的细粒度的领域服务，所以它处于架构的核心位置。
它就像一个齿轮一样进行前台应用和领域层的适配，接收前台需求，随时做出响应和调整
尽量避免将前台需求传导到领域层。应用层作为配速齿轮则位于前台应用和领域层之间。
应用层实现面向用户操作相关的用例和流程，对外提供粗粒度的 API 服务。
需求变幻无穷，但变化总是有矩可循的，用户体验、操作习惯、市场环境以及管理流程的变化，往往会导致界面逻辑和流程的多变而用例和流程则会随着外部应用需求而随时调整。
把握好这个规律，我们就知道该如何设计应用层和领域层了。但总体来说，不管前端如何变化，在企业没有大的变革的情况下，核心领域逻辑基本不会大变，所以领域模型相对稳定，而用例和流程则会随着外部应用需求而随时调整。
把握好这个规律，我们就知道该如何设计应用层和领域层了。
这三种架构都考虑了前端需求的变与领域模型的不变。
架构模型通过分层的方式来控制需求变化从外到里对系统的影响，从外向里受需求影响逐步减小
面向用户的前端可以快速响应外部需求进行调整和发布，灵活多变，应用层通过服务组合和编排来实现业务流程的快速适配上线，减少传导到领域层的需求，使领域层保持长期稳定。
就是可以保证领域层的核心业务逻辑不会因为外部需求和流程的变动而调整，对于建立前台灵活、中台稳固的架构很有帮助。
对三个架构模型分析
三种微服务架构模型的对比和分析
中台本质上是领域的子域，它可能是核心域，也可能是通用域或支撑域。
通常大家认为阿里的中台对应 DDD 的通用域，将通用的公共能力沉淀为中台，对外提供通用共享服务
中台
中台作为子域还可以继续分解为子子域，在子域分解到合适大小，通过事件风暴划分限界上下文以后，就可以定义微服务了，微服务用来实现中台的能力
微服务
表面上看，DDD、中台、微服务这三者之间似乎没什么关联，实际上它们的关系是非常紧密的，组合在一起可以作为一个理论体系用于你的中台和微服务设计。
三者的关系
中台需要站在全企业的高度考虑能力的共享和复用。
中台设计时，我们需要建立中台内所有限界上下文的领域模型，DDD 建模过程中会考虑架构演进和功能的重新组合
领域模型建立的过程会对业务和应用进行清晰的逻辑和物理边界（微服务）划分。
领域模型的结果会影响到后续的系统模型、架构模型和代码模型，最终影响到微服务的拆分和项目落地。
设计时
因此，在中台设计中我们首先要聚焦领域模型，将它放在核心位置。
1. 中台建设要聚焦领域模型
不要把与领域无关的逻辑放在领域层实现，保证领域层的纯洁和领域逻辑的稳定，避免污染领域模型。
也不要把领域模型的业务逻辑放在应用层，这样会导致应用层过于庞大，最终领域模型会失焦。
如果实在无法避免，我们可以引入防腐层，进行新老系统的适配和转换，过渡期完成后，可以直接将防腐层代码抛弃
微服务设计要有分层的设计思想，让各层各司其职，建立松耦合的层间关系。
有的微服务可以与前端应用集成，一起完成特定的业务，这是项目级微服务
领域模型的核心逻辑在领域层实现，
服务的组合和编排在应用层实现，通过 API 网关为前台应用提供服务，实现前后端分离
项目级微服务的内部遵循分层架构模型就可以了。
但项目级的微服务可能会调用其它微服务，你看在下面这张图中，比如某个项目级微服务 B 调用认证微服务 A，完成登录和权限认证
通常项目级微服务之间的集成，发生在微服务的应用层，由应用服务调用其它微服务发布在API 网关上的应用服务
你看下图中微服务 B 中红色框内的应用服务 B，它除了可以组合和编排自己的领域服务外，还可以组合和编排外部微服务的应用服务
它只要将编排后的服务发布到 API 网关供前端调用，这样前端就可以直接访问自己的微服务了。
现状
遵循原则
项目级微服务
而有的则是某个职责单一的中台微服务，企业级的业务流程需要将多个这样的微服务组合起来才能完成，
子企业级的业务流程往往是多个中台微服务一起协作完成的，那跨中台的微服务如何实现集成呢？
企业级中台微服务的集成不能像项目级微服务一样，在某一个微服务内完成跨微服务的服务组合和编排。
与项目级微服务的区别
我们可以在中台微服务之上增加一层，你看下面这张图，增加的这一层就位于红色框内，它的主要职能就是处理跨中台微服务的服务组合和编排
以及微服务之间的协调，它还可以完成前端不同渠道应用的适配。
如果再将它的业务范围扩大一些，我可以将它做成一个面向不同行业和渠道的服务平台。
我们不妨借用 BFF（服务于前端的后端，Backend for Frontends）这个词，暂且称它为BFF 微服务。
BFF 微服务与其它微服务存在较大的差异，就是它没有领域模型，因此这个微服务内也不会有领域层。
企业级中台微服务
微服务之间的集成
2. 微服务要有合理的架构分层
传统以数据为中心的设计模式，应用会对数据库、缓存、文件系统等基础资源产生严重依赖。
在微服务架构中，应用层、领域层和基础层解耦是通过仓储模式，采用依赖倒置的设计方法来实现的
在应用设计中，我们会同步考虑和基础资源的代码适配，那么一旦基础设施资源出现变更（比如换数据库），就可以屏蔽资源变更对业务代码的影响，切断业务逻辑对基础资源的依赖，最终降低资源变更对应用的影响
3. 应用和资源的解耦与适配
关注点
从三种架构模型看中台和微服务设计
08 | 微服务架构模型：几种常见模型的对比和分析
中台源于平台，但它的战略高度要比平台高很多。
阿里提出中台战略后，很多企业开始拿着自己的系统与阿里的中台对标。
有的企业在十多年前就完成了大一统的集中式系统拆分，实现了从传统大单体应用向大平台的演进，他们将公共能力和核心能力分开建设，解决了公共模块重复投入和重复建设的问题
阿里业务中台的前身是共享平台，而原来的共享平台更多的被当作资源团队
他们承接各业务方的需求，并为业务方在基础服务上做定制开发
阿里的中台背景
是把核心服务链路（会员、商品、交易、营销、店铺、资金结算等）整体当作一个平台产品来做
为前端业务提供的是业务解决方案，而不是彼此独立的系统。
阿里业务中台的目标
虽然可以通过 API 或者数据对外提供公共共享服务，解决系统重复建设的问题
并且没有将核心业务服务链路作为一个整体方案考虑，各平台仍然是分离且独立的
平台只是将部分通用的公共能力独立为共享平台。
平台解决了公共能力复用的问题，但离中台的目标显然还有一段差距！
传统企业大平台战略和阿里中台战略的差异
但这类平台并没有和企业内的其它平台或应用，实现页面、业务流程和数据从前端到后端的全面融合
与中台的本质区别
平台到底是不是中台？
中台是一个基础的理念和架构，我们要把所有的基础服务用中台的思路建设，进行联通，共同支持上端的业务
业务中台更多的是支持在线业务，数据中台提供了基础数据处理能力和很多的数据产品给所有业务方去用。
业务中台、数据中台、算法中台等等一起提供对上层业务的支撑。
阿里的定义
中台是企业级能力复用平台
思特沃克对中台的定义
联通是前台以及中台之间的联通
融合是前台流程和数据的融合
并以共享的方式支持前端一线业务的发展和创新。
共享、联通、融合和创新
提炼出几个关于中台的关键词
中台首先体现的是一种企业级的能力，它提供的是一套企业级的整体解决方案，解决小到企业、集团，大到生态圈的能力共享、联通和融合问题，支持业务和商业模式创新。
通过平台联通和数据融合为用户提供一致的体验，更敏捷地支撑前台一线业务。
作者观点
中台来源于平台，但中台和平台相比，它更多体现的是一种理念的转变
对前台业务的快速响应能力
企业级复用能力
从前台、中台到后台的设计、研发、页面操作、流程服务和数据的无缝联通、融合能力。
它主要体现在这三个关键能力上
其中最关键的是快速响应能力和企业级的无缝联通和融合能力，尤其是对于跨业经营的超大型企业来说至关重要。
中台与平台的区别
中台到底是什么？
有面向内部人员的门店类应用
面向外部用户的互联网电商以及移动 APP 类应用
这些应用面向的用户和场景可能不同，但其功能类似，基本涵盖了核心业务能力。
此外，传统企业也会将部分核心应用的页面或 API服务能力开放给生态圈第三方，相互借力发展
相对互联网企业而言，传统企业的渠道应用更多样化
为了适应不同业务和渠道的发展，过去很多企业的做法是开发很多独立的应用或 APP
但由于 IT 系统建设初期并没有企业级的整体规划，平台之间融合不好，就导致了用户体验不好，最关键的是用户并不想装那么多 APP。
过去的做法
为了提升用户体验，实现统一运营，很多企业开始缩减 APP 的数量
开始通过一个 APP集成企业内的所有能力，联通前台所有的核心业务链路。
优化后的做法
由于传统企业的商业模式和 IT 系统建设发展的历程与互联网企业不是完全一样的
因此传统企业的中台建设策略与阿里中台战略也应该有所差异，需要共享的内容也不一样。
传统企业还需要将核心能力中台化，以满足不同渠道的核心业务能力共享和复用的需求
避免传统核心和互联网不同渠道应用出现“后端双核心、前端两张皮”的问题，这里的核心能力对应 DDD 的核心域。
由于渠道多样化，传统企业不仅要将通用能力中台化，以实现通用能力的沉淀、共享和复用，这里的通用能力对应 DDD 的通用域或支撑域
这就属于业务中台的范畴了，我们需要解决核心业务链路的联通和不同渠道服务共享的问题。
除此之外，我们还需要解决系统微服务拆分后的数据孤岛、数据融合和业务创新等问题，这就属于数据中台的范畴了
尤其是当我们采用分布式架构以后，我们就更应该关注微服务拆分后的数据融合和共享问题了。
在中台设计和规划时，我们需要整体考虑企业内前台、中台以及后台应用的协同
实现不同渠道应用的前端页面、流程和服务的共享
还有核心业务链路的联通以及前台流程和数据的融合、共享，支持业务和商业模式的创新。
数字化转型中台应该共享什么？
如果把业务中台比作陆军、火箭军和空军等专业军种的话，它主要发挥战术专业能力
前台就是作战部队，它需要根据前线的战场需求，对业务中台的能力进行调度，实现能力融合和效率最大化
而数据中台就是信息情报中心和联合作战总指挥部，它能够汇集各种数据、完成分析，制定战略和战术计划
后台就是后勤部队，提供技术支持
传统企业的早期系统有不少是基于业务领域或组织架构来建设的
每个系统都有自己的前端，相互独立，用户操作是竖井式，需要登录多个系统才能完成完整的业务流程。
以实现各不同中台前端操作、流程和界面的联通、融合
不管后端有多少个中台，前端用户感受到的就是只有一个前台。
中台后的前台建设要有一套综合考虑业务边界、流程和平台的整体解决方案
在前台设计中我们可以借鉴微前端的设计思想，在企业内不仅实现前端解耦和复用
还可以根据核心链路和业务流程，通过对微前端页面的动态组合和流程编排，实现前台业务的融合。
前端页面可以很自然地融合到不同的终端和渠道应用核心业务链路中，实现前端页面、流程和功能复用。
1. 前台
传统企业的核心业务大多是基于集中式架构开发的，而单体系统存在扩展性和弹性伸缩能力差的问题，因此无法适应忽高忽低的互联网业务场景
而数据类应用也多数通过 ETL 工具抽取数据实现数据建模、统计和报表分析功能，但由于数据时效和融合能力不够
再加上传统数据类应用本来就不是为前端而生的，因此难以快速响应前端一线业务。
通过领域建模，将可复用的公共能力从各个单体剥离，沉淀并组合
采用微服务架构模式，建设成为可共享的通用能力中台。
业务中台向前台、第三方和其它中台提供 API 服务，实现通用能力和核心能力的复用。
我们可以将核心能力用微服务架构模式，建设成为可面向不同渠道和场景的可复用的核心能力中台
在将传统集中式单体按业务职责和能力细分为微服务，建设中台的过程中，会产生越来越多的独立部署的微服务
这样做虽然提升了应用弹性和高可用能力，但由于微服务的物理隔离，原来一些系统内的调用会变成跨微服务调用
再加上前后端分离，微服务拆分会导致数据进一步分离，增加企业级应用集成的难度。
如果没有合适的设计和指导思想，处理不好前台、中台和后台的关系，将会进一步加剧前台流程和数据的孤岛化、碎片化。
注意几点
业务中台的建设可采用领域驱动设计方法
数据中台的主要目标是打通数据孤岛，实现业务融合和创新，包括三大主要职能：
主要目标
一是完成企业全域数据的采集与存储，实现各不同业务类别中台数据的汇总和集中管理。
比如客户视图、代理人视图、渠道视图、机构视图等不同数据体系。
二是按照标准的数据规范或数据模型，将数据按照不同主题域或场景进行加工和处理，形成面向不同主题和场景的数据应用
三是建立业务需求驱动的数据体系，基于各个维度的数据，深度萃取数据价值，支持业务和商业模式的创新。
三大职能
第一步实现各中台业务数据的汇集，解决数据孤岛和初级数据共享问题。
第二步实现企业级实时或非实时全维度数据的深度融合、加工和共享。
第三步萃取数据价值，支持业务创新，加速从数据转换为业务价值的过程。
相应的，数据中台的建设就可分为三步走：
数据中台不仅限于分析型场景，也适用于交易型场景
它可以建立在数据仓库或数据平台之上，将数据服务化之后提供给业务系统
基于数据库日志捕获的技术，使数据的时效性大大提升，这样就可以为交易型场景提供很好的支撑
数据中台主要完成数据的融合和加工，萃取数据业务价值，支持业务创新，对外提供数据共享服务。
数据中台
2. 中台
前台主要面向客户以及终端销售者，实现营销推广以及交易转化
中台主要面向运营人员，完成运营支撑
为了实现内部的管理要求，很多人习惯性将这些管理要求嵌入到核心业务流程中。
而一般来说这类内控管理需求对权限、管控规则和流程等要求都比较高，但是大部分管理人员只是参与了某个局部业务环节的审核
这类复杂的管理需求，会凭空增加不同渠道应用前台界面和核心流程的融合难度以及软件开发的复杂度。
后台主要面向后台管理人员，实现流程审核、内部管理以及后勤支撑，比如采购、人力、财务和 OA 等系统。
前台，后台，中台
3. 后台
如何实现前中后台的协同？
09 | 中台：数字转型后到底应该共享什么？
中台是抽象出来的业务模型
微服务是业务模型的系统实现
DDD作为方法论可以同时指导中台业务建模和微服务建设，三者相辅相成，完美结合
DDD 有两把利器，那就是它的战略设计和战术设计方法
中台在企业架构上更多偏向业务模型，形成中台的过程实际上也是业务领域不断细分的过程。
在这个过程中我们会将同类通用的业务能力进行聚合和业务重构，再根据限界上下文和业务内聚的原则建立领域模型
而 DDD 的战略设计最擅长的就是领域建模
中台和DDD
那在中台完成领域建模后，我们就需要通过微服务来完成系统建设。
DDD 的战术设计又恰好可以与微服务的设计完美结合
可以说，中台和微服务正是 DDD 实战的最佳场景。
微服务和DDD
在研究和解决业务问题时，DDD 会按照一定的规则将业务领域进行细分
领域细分到一定的程度后，DDD 会将问题范围限定在特定的边界内
并在这个边界内建立领域模型，进而用代码实现该领域模型，解决相应的业务问题。
领域可分解为子域，子域可继续分为子子域，一直到你认为适合建立领域模型为止。
子域还会根据自身重要性和功能属性划分为三类子域，
分类规则
支撑域
三类子域
每个企业的领域定位和职责会有些不一样，那在核心域的划分上肯定会有一定差异
因此，当你去做领域划分的时候，请务必结合企业战略，这恰恰也体现了 DDD 领域建模的重要性。
通过领域划分和进一步的子域划分，我们就可以区分不同子域在企业内的功能属性和重要性
进而采取不同的资源投入和建设策略，这在企业 IT 系统的建设过程中十分重要
并且这样的划分还可以帮助企业进行中台设计。
子域分类
DDD 的本质
其实就是提炼各个业务板块的共同需求，进行业务和系统抽象
形成通用的可复用的业务模型，打造成组件化产品，供前台部门使用
前台要做什么业务，需要什么资源，可以直接找中台，不需要每次都去改动自己的底层。
中台的本质
传统企业可以将需要共享的公共能力进行领域建模，建设可共享的通用中台
除此之外，传统企业还会将核心能力进行领域建模，建设面向不同渠道的可复用的核心中台。
而这里的通用中台和核心中台都属于我们上一讲讲到的业务中台的范畴。
划分这几个子域的主要目的是为了确定战略资源的投入
一般来说战略投入的重点是核心域，因此后面我们就可以暂时不严格区分支撑域和通用域了。
DDD 的子域分为核心域、通用域和支撑域。
领域、中台以及微服务虽然属于不同层面的东西，但我们还是可以将他们分解对照，整理出来它们之间的关系
我是从 DDD 领域建模和中台建设这两个不同的视角对同一个企业的业务架构进行分析。
在进行领域细分时，从 DDD 视角来看，子域可分为核心域、通用域和支撑域。
从中台建设的视角来看，业务域细分后的业务中台，可分为核心中台和通用中台。
如果将企业内整个业务域作为一个问题域的话，企业内的所有业务就是一个领域
通用中台对应 DDD 的通用域和支撑域，核心中台对应DDD 的核心域
从领域的功能范围来看，子域与中台是一致的。领域模型所在的限界上下文对应微服务
建立了这个映射关系，我们就可以用 DDD 来进行中台业务建模了。
从领域功能属性和重要性对照来看
第一类是提供保险核心业务能力的核心中台（比如营销、承保和理赔等业务）；
第二类是支撑核心业务流程完成保险全流程的通用中台（比如订单、支付、客户和用户等）。
保险域的业务中台分为两类
根据 DDD 首先要建立通用语言的原则，在将 DDD 的方法引入中台设计时，我们要先建立中台和 DDD 的通用语言
这里的子域与中台是一致的，那我们就可以将子域统一为中台
中台通过事件风暴可以进一步细分，最终完成业务领域建模。
中台业务领域的功能不同，限界上下文的数量和大小就会不一样，领域模型也会不一样。
当完成业务建模后，我们就可以采用 DDD 战术设计，设计出聚合、实体、领域事件、领域服务以及应用服务等领域对象
再利用分层架构模型完成微服务的设计
我们这里还是以保险领域为例。
DDD、中台和微服务的协作模式
中台业务抽象的过程就是业务建模的过程，对应 DDD 的战略设计
系统抽象的过程就是微服务的建设过程，对应 DDD 的战术设计。
按照业务流程（通常适用于核心域）或者功能属性、集合（通常适用于通用域或支撑域）
将业务域细分为多个中台，再根据功能属性或重要性归类到核心中台或通用中台。
核心中台设计时要考虑核心竞争力，通用中台要站在企业高度考虑共享和复用能力
选取中台，根据用例、业务场景或用户旅程完成事件风暴
找出实体、聚合和限界上下文
依次进行领域分解，建立领域模型。
由于不同中台独立建模，某些领域对象或功能可能会重复出现在其它领域模型中
也有可能本该是同一个聚合的领域对象或功能，却分散在其它的中台里，这样会导致领域模型不完整或者业务不内聚
这里先不要着急，这一步我们只需要初步确定主领域模型就可以了，在第三步中我们还会提炼并重组这些领域对象
以主领域模型为基础，扫描其它中台领域模型，检查并确定是否存在重复或者需要重组的领域对象、功能，提炼并重构主领域模型，完成最终的领域模型设计。
选择其它主领域模型重复第三步，直到所有主领域模型完成比对和重构。
第四步：
基于领域模型完成微服务设计，完成系统落地。
第五步：
主要为：业务域分解为中台，对中台归类，完成领域建模
建立中台业务模型。
DDD 战略设计包括上述的第一步到第四步
DDD 战术设计是第五步，领域模型映射为微服务，完成中台建设。
下面我们就结合 DDD 领域建模的方法，讲一下中台业务建模的过程。
中台如何建模？
10 | DDD、中台和微服务：它们是如何协作的？
两者面向的渠道和客户不一样
但销售的产品却很相似。
它们之间的业务模型既有相同的地方，又有不同的地方
互联网电商平台和传统核心应用的区别
由于销售同质保险产品，二者在核心业务流程和功能上必然相似，因此在核心业务能力上存在功能重叠是不可避免的
传统保险核心应用有报价、投保、核保和出单功能，同样在互联网电商平台也有。这就是核心能力的重复建设。
1. 核心能力的重复建设
传统核心应用的通用平台大而全，通常会比较重。
而互联网电商平台离不开这些通用能力的支撑，但为了保持敏捷性，一般会自己建设缩小版的通用功能，比如用户、客户等
这是通用能力的重复建设。
2. 通用能力的重复建设
有一类业务功能，在互联网电商平台中建设了一部分，
在传统核心应用中也建设了一部分，二者功能不重叠而且还互补，组合在一起是一个完整的业务职能
比如缴费功能，互联网电商平台主要面向个人客户，于是采用了支付宝和微信支付的方式
互联网电商平台
而传统核心应用主要是柜台操作，仍在采用移动 POS 机的缴费方式
传统核心应用
二者都是缴费，为了保证业务模型的完整性，在构建中台业务模型时，我们可以考虑将这两部分模型重组为一个完整的业务模型。
3. 业务职能的分离建设
传统核心应用主要面向柜台，不需要互联网电商平台的在线客户、话务、订单和购物车等功能
而互联网电商平台主要面向个人客户，它不需要后端比较重的再保、佣金、打印等功能。
在构建中台业务模型时，对这种情况应区别对待，将面向后端业务管理的应用沉淀到后台，将前端能力构建为面向互联网渠道的通用中台，比如订单等。
4. 互联网电商平台和传统核心功能前后完全独立建设。
建设
保险行业的互联网电商和传统核心应用来做个对比分析
传统企业应用分析
“复用”用白话说就是重复使用，就是要避免重复造轮子的事情。
高内聚是把相关的业务行为聚集在一起，把不相关的行为放在其它地方，如果你要修改某个业务行为，只需要修改一处
对了！中台就是要这样做，按照“高内聚、松耦合”的原则，实现企业级的能力复用！
中台的设计思想与“高内聚、低耦合”的设计原则是高度一致的。
你需要站在企业高度，将重复的需要共享的通用能力、核心能力沉淀到中台，将分离的业务能力重组为完整的业务板块，构建可复用的中台业务模型。
前端个性能力归前端，后端管理能力归后台
建立前、中、后台边界清晰，融合协作的企业级可复用的业务模型。
遇到重复造轮子，怎么处理
如何避免重复造轮子？
这种策略是先做顶层设计
从最高领域逐级分解为中台
领域建模过程主要基于业务现状，暂时不考虑系统现状
分别建立领域模型
根据业务属性分为通用中台或核心中台
自顶向下的策略适用于全新的应用系统建设，或旧系统推倒重建的情况。
由于这种策略不必受限于现有系统，你可以用 DDD 领域逐级分解的领域建模方法
第一步是将领域分解为子域，子域可以分为核心域、通用域和支撑域
第二步是对子域建模，划分领域边界，建立领域模型和限界上下文
第三步则是根据限界上下文进行微服务设计。
主要步骤
1. 自顶向下的策略
这种策略是基于业务和系统现状完成领域建模。
自底向上策略适用于遗留系统业务模型的演进式重构
首先分别完成系统所在业务域的领域建模；
然后对齐业务域，找出具有同类或相似业务功能的领域模型
对比分析领域模型的差异，重组领域对象，重构领域模型
这个过程会沉淀公共和复用的业务能力，会将分散的业务模型整合
好处
锁定系统所在的业务域，采用事件风暴，找出领域对象，构建聚合，划分限界上下文，建立领域模型
其中用户域构建了用户认证和权限两个领域模型
客户域构建了个人和团体两个领域模型
传统收付构建了 POS 刷卡领域模型
承保域构建了定报价
投保和保单管理三个领域模型。
传统核心共构建了八个领域模型
互联网电商构建了报价、投保、订单、客户、用户认证和移动收付六个领域模型。
在这些领域模型的清单里，我们可以看到二者之间有很多名称相似的领域模型。
深入分析后你会发现，这些名称相似的领域模型存在业务能力重复，或者业务职能分散（比如移动支付和传统支付）的问题
那在构建中台业务模型时，你就需要重点关注它们，将这些不同领域模型中重复的业务能力沉淀到中台业务模型中，将分散的领域模型整合到统一的中台业务模型中，对外提供统一的共享的中台服务。
第一步：锁定系统所在业务域，构建领域模型。
可以看到右侧的传统核心领域模型明显多于左侧的互联网电商
传统核心面向企业内大部分应用，大而全，领域模型相对完备
而互联网电商面向单一渠道，领域模型相对单一
那我们是不是就可以得出一个初步的结论：
首先我们可以将传统核心的领域模型作为主领域模型，将互联网电商领域模型作为辅助模型来构建中台业务模型
然后再将互联网电商中重复的能力沉淀到传统核心的领域模型中，只保留自己的个性能力，比如订单
中台业务建模时，既要关注领域模型的完备性，也要关注不同渠道敏捷响应市场的要求。
这个结论也给我们指明了一个方向
分析现状
互联网电商客户主要面向个人客户，除了有个人客户信息管理功能外
基于营销目的它还有客户积分功能，因此它的领域模型有个人和积分两个聚合。
而传统核心客户除了支持个人客户外，还有单位和组织机构等团体客户，它有个人和团体两个领域模型
其中个人领域模型中除了个人客户信息管理功能外，还有个人客户的评级、重复客户的归并和客户的统一视图等功能
因此它的领域模型有个人、视图、评级和归并四个聚合。
传统企业
构建多业务域的中台业务模型的过程，就是找出同一业务域内所有同类业务的领域模型
对比分析域内领域模型和聚合的差异和共同点，打破原有的模型，完成新的中台业务模型重组或归并的过程。
个人、积分、评级、归并和视图
我们将互联网电商和传统核心的领域模型分解后，我们找到了五个与个人客户领域相关的聚合，包括：
这五个聚合原来分别分散在互联网电商和传统核心的领域模型中，我们需要打破原有的领域模型，进行功能沉淀和聚合的重组，重新找出这些聚合的限界上下文，重构领域模型
个人、归并和视图三个聚合重构为个人领域模型（客户信息管理）
评级和积分两个聚合重构为评级积分领域模型（面向个人客户）。
到这里我们就完成了个人客户领域模型的构建了。
最终个人客户的领域模型重构为：
由于它只在传统核心中出现，我们将它在传统核心中的领域模型直接拿过来用就行了。
对了，还有团队客户领域模型！其实团体客户很简单。
至此我们就完成了客户中台业务模型的构建了，客户中台构建了个人、团体和评级积分三个领域模型。
结论
分域建模型，找准基准域，划定上下文，聚合重归类
总结成一句话
下面我以客户为例，来给你讲一下客户中台业务模型的构建过程。
第二步：对齐业务域，构建中台业务模型。
从这张图中我们可以看到总共构建了多少个中台
中台下面有哪些领域模型，
哪些中台是通用中台，哪些中台是核心中台，中台的基本信息等等，都一目了然
你根据中台下的领域模型就可以设计微服务了。
完成中台业务建模后，我们就有了下面这张图。
第三步：中台归类，根据领域模型设计微服务。
三个步骤
2. 自底向上的策略
如何构建中台业务模型？
上面主要是从聚合的角度来描述中台业务模型的重组，是相对高阶的业务模块的重构
业务模型重构和聚合重组，往往会带来领域对象和业务行为的变化
下面我带你了解一下，在领域模型重组过程中，发生在更底层的领域对象的活动。
我们还是以客户为例来讲述。由于对象过多，我只选取了部分领域对象和业务行为。
传统核心客户领域模型重构之前，包含个人、团体和评级三个聚合，每个聚合内部都有自己的聚合根、实体、方法和领域服务等
传统核心客户
互联网电商客户领域模型重构前包含个人和积分两个聚合，每个聚合包含了自己的领域对象、方法和领域服务等
互联网电商客户
重构后
传统核心和互联网电商客户领域模型重构成客户中台后，建立了个人、团体和评级积分三个领域模型。
其中个人领域模型有个人聚合，团体领域模型有团体聚合，评级积分领域模型有评级和积分两个聚合
这些领域模型的领域对象来自原来的领域模型，但积分评级是重组后的领域模型，它们原来的聚合会带着各自的领域对象，加入到新的领域模型中。
部分领域对象可能会根据新的业务要求，从原来的聚合中分离，重组到其它聚合。
新领域模型的领域对象，比如实体、领域服务等，在重组后可能还会根据新的业务场景和需求进行代码重构。
重构过程中的领域对象
11 | DDD实践：如何用DDD重构中台业务模型？
事件风暴是一项团队活动，领域专家与项目团队通过头脑风暴的形式，罗列出领域中所有的领域事件，整合之后形成最终的领域事件集合
然后对每一个事件，标注出导致该事件的命令，再为每一个事件标注出命令发起方的角色。
命令可以是用户发起，也可以是第三方系统调用或者定时器触发等，
最后对事件进行分类，整理出实体、聚合、聚合根以及限界上下文
而事件风暴正是 DDD 战略设计中经常使用的一种方法，它可以快速分析和分解复杂的业务领域，完成领域建模。
重要
很多公司可能并没有这个角色，那我们该寻找什么样的人来担当领域专家呢？
如果你的公司里并没有这个角色，那也没关系，你可以从业务人员、需求分析人员、产品经理或者在这个领域有多年经验的开发人员里，按照这个标准去选择合适的人选。
领域专家是事件风暴中必不可少的核心参与者。
事件风暴的其他参与者可以是 DDD 专家、架构师、产品经理、项目经理、开发人员和测试人员等项目团队成员。
领域建模是统一团队语言的过程，因此项目团队应尽早地参与到领域建模中，这样才能高效建立起团队的通用语言
到了微服务建设时，领域模型也更容易和系统架构保持一致
1. 事件风暴的参与者
事件风暴参与者会将自己的想法和意见写在即时贴上，并将贴纸贴在墙上的合适位置，我们戏称这个过程是“刷墙”
所以即时贴和水笔是必备材料
另外，你还可以准备一些胶带或者磁扣，以便贴纸随时能更换位置。
补充信息主要用来说明注意事项，比如外部依赖等。
蓝色表示命令，用绿色表示实体，橙色表示领域事件，黄色表示补充信息等
2. 事件风暴要准备的材料
墙是用来贴纸的，
大空间可以让人四处走动，方便合作
撤掉会议桌和椅子的事件风暴，你会发现参与者们的效率更高。
只需要一堵足够长的墙和足够大的空间就可以了。
3. 事件风暴的场地
在领域建模的过程中，我们需要重点关注这类业务的语言和行为
比如某些业务动作或行为（事件）是否会触发下一个业务动作，这个动作（事件）的输入和输出是什么？
是谁（实体）发出的什么动作（命令），触发了这个动作（事件）…我们可以从这些暗藏的词汇中，分析出领域模型中的事件、命令和实体等领域对象。
4. 事件风暴分析的关注点
事件风暴需要准备些什么？
主要目的是对产品顶层价值的设计，使产品目标用户、核心价值、差异化竞争点等信息达成一致，避免产品偏离方向。
领域专家、业务需求方、产品经理、项目经理和开
参与角色
用户中台到底能够做什么？
它的业务范围、目标用户、核心价值和愿景，与其它同类产品的差异和优势在哪里？
在建模之前，项目团队要思考这样两点：
这个过程也是明确用户中台建设方向和统一团队思想的过程。
参与者要对每一个点（下图最左侧列的内容）发表意见，用水笔写在贴纸上，贴在黄色贴纸的位置
这个过程会让参与者充分发表意见，最后会将发散的意见统一为通用语言，建立如下图的产品愿景墙
如果你的团队的产品愿景和目标已经很清晰了，那这个步骤你可以忽略。
过程
1. 产品愿景
场景分析是从用户视角出发的，根据业务流程或用户旅程，采用用例和场景分析，探索领域中的典型场景，找出领域事件、实体和命令等领域对象，支撑领域建模
事件风暴参与者要尽可能地遍历所有业务细节，充分发表意见，不要遗漏业务要点。
领域专家、产品经理、需求分析人员、架构师、项目经理、开发经理和测试经理。
场景分析的参与角色
第一个是系统和岗位设置，设置系统中岗位的菜单权限；
第二个是用户权限配置，为用户建立账户和密码，设置用户岗位；
第三个是用户登录系统和权限校验，生成用户登录和操作日志。
用户中台有这样三个典型的业务场景：
我们可以按照业务流程，一步一步搜寻用户业务流程中的关键领域事件，比如岗位已创建，用户已创建等事件
比如创建用户时，第一个命令是从公司 HR 系统中获取用户信息
第二个命令是根据 HR 的员工信息在用户中台创建用户，创建完用户后就会产生用户已创建的领域事件
当然这个领域事件可能会触发下一步的操作，比如发布到邮件系统通知用户已创建，但也可能到此就结束了，你需要根据具体情况来分析是否还有下一步的操作
再找出什么行为会引起这些领域事件，这些行为可能是一个或若干个命令组合在一起产生的
我用蓝色来表示命令，用橙色表示领域事件，用黄色表示补充信息
场景分析时会产生很多的命令和领域事件。
2. 业务场景分析
领域建模时，我们会根据场景分析过程中产生的领域对象，比如命令、事件等之间关系
找出产生命令的实体，分析实体之间的依赖关系组成聚合，为聚合划定限界上下文，建立领域模型以及模型之间的依赖。
领域模型利用限界上下文向上可以指导微服务设计，通过聚合向下可以指导聚合根、实体和值对象的设计
领域建模的参与角色
用绿色贴纸表示实体。
从命令和事件中提取产生这些行为的实体。
通过分析用户中台的命令和事件等行为数据，提取了产生这些行为的用户、账户、认证票据、系统、菜单、岗位和用户日志七个实体。
比如，用户管理用户相关实体以及值对象，系统可以管理与系统相关的菜单等实体等，可以找出用户和系统等聚合根。
根据聚合根的管理性质从七个实体中找出聚合根
比如系统和菜单实体可以组合为“系统功能”聚合
然后根据业务依赖和业务内聚原则，将聚合根以及它关联的实体和值对象组合为聚合
按照上述方法，用户中台就有了系统功能、岗位、用户信息、用户日志、账户和认证票据六个聚合。
划定限界上下文，根据上下文语义将聚合归类。
根据用户域的上下文语境，用户基本信息和用户日志信息这两个聚合共同构成用户信息域，分别管理用户基本信息、用户登录和操作日志
认证票据和账户这两个聚合共同构成认证域，分别实现不同方式的登录和认证。
系统功能和岗位这两个聚合共同构成权限域，分别实现系统和菜单管理以及系统的岗位配置
根据业务边界，我们可以将用户中台划分为三个限界上下文：用户信息、认证和权限。
到这里我们就完成了用户中台领域模型的构建了
那由于领域建模的过程中产生的领域对象实在太多了，我们可以借助表格来记录。
具体可以分为这样三步
3. 领域建模
原则上一个领域模型就可以设计为一个微服务，但由于领域建模时只考虑了业务因素
没有考虑微服务落地时的技术、团队以及运行环境等非业务因素
因此在微服务拆分与设计时，我们不能简单地将领域模型作为拆分微服务的唯一标准，它只能作为微服务拆分的一个重要依据。
微服务的设计还需要考虑服务的粒度、分层、边界划分、依赖关系和集成关系
除了考虑业务职责单一外
将敏态与稳态业务的分离
非功能性需求（如弹性伸缩要求、安全性等要求）
团队组织和沟通效率
软件包大小以及技术异构等非业务因素。
还要考虑
考虑的因素
微服务设计建议参与的角色
我们完全可以按照领域模型与微服务一对一的关系来设计
将用户中台设计为：用户、认证和权限三个微服务
用户中台微服务设计如果不考虑非业务因素
但如果用户日志数据量巨大，大到需要采用大数据技术来实现，这时用户信息聚合与用户日志聚合就会有技术异构。
虽然在领域建模时，我们将他们放在一个了领域模型内，但如果考虑技术异构，这两个聚合就不适合放到同一个微服务里了
我们可以以聚合作为拆分单位，将用户基本信息管理和用户日志管理拆分为两个技术异构的微服务，分别用不同的技术来实现它们
4. 微服务拆分与设计
如何用事件风暴构建领域模型？
DDD: 事件风暴--产品愿景--场景分析--领域建模--微服务拆分与设计。
传统: 产品需求--需求分析--详细设计--ER模型--UML设计
12 | 领域建模：如何用事件风暴构建领域模型？
只有建立了标准的微服务代码模型和代码规范后，我们才可以将领域对象所对应的代码对象放在合适的软件包的目录结构中。
标准的代码模型可以让项目团队成员更好地理解代码，根据代码规范实现团队协作
还可以让微服务各层的逻辑互不干扰、分工协作、各据其位、各司其职，避免不必要的代码混淆。
另外，标准的代码模型还可以让你在微服务架构演进时，轻松完成代码重构。
我们参考 DDD 分层架构模型来设计微服务代码模型
微服务代码模型就是依据DDD 分层架构模型设计出来的
面向前端提供服务适配，面向资源层提供资源适配。这一层聚集了接口适配相关的功能。
实现服务组合和编排，适应业务流程快速变化的需求。这一层聚集了应用服务和事件相关的功能
应用层职责
实现领域的核心业务逻辑。这一层聚集了领域模型的聚合、聚合根、实体、值对象、领域服务和事件等领域对象，以及它们组合所形成的业务能力
贯穿所有层，为各层提供基础资源服务。这一层聚集了各种底层资源相关的服务和能力。
DDD 分层架构与微服务代码模型
DDD 并没有给出标准的代码模型，不同的人可能会有不同理解
下面要说的这个微服务代码模型是我经过思考和实践后建立起来的，主要考虑的是微服务的边界、分层以及架构演进。
在代码模型里分别为用户接口层、应用层、领域层和基础层
建立了 interfaces、application、domain 和 infrastructure 四个一级代码目录。这
它主要存放用户接口层与前端交互、展现数据相关的代码
前端应用通过这一层的接口，向应用服务获取展现所需的数据
这一层主要用来处理用户发送的 Restful 请求，解析用户输入的配置文件，并将数据传递给 Application 层
数据的组装、数据传输格式以及 Facade 接口等代码都会放在这一层目录里。
实现 DTO 与领域对象之间的相互转换和数据交换。一般来说 Assembler 与DTO 总是一同出现
Assembler
它是数据传输的载体，内部不存在任何业务逻辑，我们可以通过 DTO 把内部的领域对象与外界隔离
Dto
提供较粗粒度的调用接口，将用户请求委派给一个或多个应用服务进行处理。
Facade
assembler、dto 和 façade 三类
代码目录结构
Interfaces（用户接口层）
它主要存放应用层服务组合和编排相关的代码
应用服务向下基于微服务内的领域服务或外部微服务的应用服务完成服务的编排和组合，向上为用户接口层提供各种应用数据展现支持服务
应用服务和事件等代码会放在这一层目录里。
这层目录主要存放事件相关的代码
前者主要存放事件发布相关代码
后者主要存放事件订阅相关代码（事件处理相关的核心业务逻辑在领域层实现）
它包括两个子目录：publish 和subscribe。
Event（事件）
应用服务会对多个领域服务或外部应用服务进行封装、编排和组合，对外提供粗粒度的服务
应用服务主要实现服务组合和编排，是一段独立的业务逻辑
你可以将所有应用服务放在一个应用服务类里，也可以把一个应用服务设计为一个应用服务类，以防应用服务类代码量过大。
这层的服务是应用服务。
Service（应用服务）
Application 的代码目录结构有：event 和 service。
代码的目录结构
Application（应用层）
领域层可以包含多个聚合代码包，它们共同实现领域模型的核心业务逻辑
聚合以及聚合内的实体、方法、领域服务和事件等代码会放在这一层目录里。
Domain 是由一个或多个聚合包构成，共同实现领域模型的核心业务逻辑
它是聚合软件包的根目录，可以根据实际项目的聚合名称命名，比如权限聚合
在聚合内定义聚合根、实体和值对象以及领域服务之间的关系和边界
聚合内实现高内聚的业务逻辑，它的代码可以独立拆分为微服务。
以聚合为单位的代码放在一个包里的主要目的是为了业务内聚，而更大的目的是为了以后微服务之间聚合的重组
聚合之间清晰的代码边界，可以让你轻松地实现以聚合为单位的微服务重组，在微服务架构演进中有着很重要的作用。
Aggregate（聚合）
它存放聚合根、实体、值对象以及工厂模式（Factory）相关代码
实体类采用充血模型，同一实体相关的业务逻辑都在实体类代码中实现。
跨实体的业务逻辑代码在领域服务中实现。
Entity（实体）
它存放事件实体以及与事件活动相关的业务逻辑代码。
你可以将聚合内所有领域服务都放在一个领域服务类中，你也可以把每一个领域服务设计为一个类
如果领域服务内的业务逻辑相对复杂，我建议你将一个领域服务设计为一个领域服务类，避免由于所有领域服务代码都放在一个领域服务类中，而出现代码臃肿的问题。
领域服务封装多个实体或方法后向上层提供应用服务调用
Service（领域服务）
它存放所在聚合的查询或持久化领域对象的代码，通常包括仓储接口和仓储实现方法
为了方便聚合的拆分和组合，我们设定了一个原则：一个聚合对应一个仓储。
Repository（仓储）
聚合内的代码模型是标准和统一的，包括：entity、event、repository 和 service 四个子目录
代码目录结构
按照 DDD 分层架构，仓储实现本应该属于基础层代码，但为了在微服务架构演进时，保证代码拆分和重组的便利性，我是把聚合仓储实现的代码放到了聚合包内。
如果需求或者设计发生变化导致聚合需要拆分或重组时，我们就可以将包括核心业务逻辑和仓储代码的聚合包整体迁移，轻松实现微服务架构演进。
特别说明
Domain（领域层）
它主要存放基础资源服务相关的代码，为其它各层提供的通用技术能力、三方软件包、数据库服务、配置和基础资源服务的代码都会放在这一层目录里
主要存放配置相关代码
Config
主要存放平台、开发框架、消息、数据库、缓存、文件、总线、网关、第三方类库、通用算法等基础代码，你可以为不同的资源类别建立不同的子目录
Util
config 和 util 两个子目录
Infrastructure（基础层）
微服务一级目录是按照 DDD 分层架构的分层职责来定义的
代码模型总目录结构
微服务一级目录结构
微服务代码模型
13 | 代码模型（上）：如何使用DDD设计微服务代码模型？
DDD 强调先构建领域模型然后设计微服务，以保证领域模型和微服务的一体性，因此我们不能脱离领域模型来谈微服务的设计和落地
但在构建领域模型时，我们往往是站在业务视角的，并且有些领域对象还带着业务语言
我们还需要将领域模型作为微服务设计的输入，对领域对象进行设计和转换，让领域对象与代码对象建立映射关系
完成微服务拆分后，领域模型的边界和领域对象就基本确定
比如：聚合、实体、命令和领域事件等内容，将这些领域对象和业务行为记录到下面的表格中。
这张表格里包含了：领域模型、聚合、领域对象和领域类型四个维度
一个领域模型会包含多个聚合
一个聚合包含多个领域对象
每个领域对象都有自己的领域类型
领域类型主要标识领域对象的属性，比如：聚合根、实体、命令和领域事件等类型。
第一个重要的工作:整理事件风暴过程中产生的各个领域对象
领域对象的整理
从领域模型到微服务落地，我们还需要做进一步的设计和分析
事件风暴中提取的领域对象，还需要经过用户故事或领域故事分析，以及微服务设计，才能用于微服务系统开发。
分析微服务内有哪些服务？
服务所在的分层？
应用服务由哪些服务组合和编排完成？
领域服务包括哪些实体的业务逻辑？
采用充血模型的实体有哪些属性和方法？
有哪些值对象？
哪个实体是聚合根等？
最后梳理出所有的领域对象和它们之间的依赖关系，我们会给每个领域对象设计对应的代码对象，定义它们所在的软件包和代码目录。
这个过程会比事件风暴来的更深入和细致。主要关注内容如下：
DDD 专家、架构师、设计人员和开发经理。领域
这个设计过程建议参与的角色有
从领域模型到微服务的设计
事件风暴结束时，领域模型聚合内一般会有：聚合、实体、命令和领域事件等领域对象
聚合、聚合根、实体、值对象、领域事件、领域服务和仓储等领域对象。
在完成故事分析和微服务设计后，微服务的聚合内一般会有
大多数情况下，领域模型的业务实体与微服务的数据库实体是一一对应的
但某些领域模型的实体在微服务设计时，可能会被设计为多个数据实体，或者实体的某些属性被设计为值对象。
我们分析个人客户时，还需要有地址、电话和银行账号等实体，它们被聚合根引用
在分层架构里，实体采用充血模型，在实体类内实现实体的全部业务逻辑
这些不同的实体都有自己的方法和业务行为，比如地址实体有新增和修改地址的方法，银行账号实体有新增和修改银行账号的方法。
逻辑
实体类放在领域层的 Entity 目录结构下。
位置
1. 设计实体
聚合根来源于领域模型，在个人客户聚合里，个人客户这个实体是聚合根，它负责管理地址、电话以及银行账号的生命周期
来自哪里
个人客户聚合根通过工厂和仓储模式，实现聚合内地址、银行账号等实体和值对象数据的初始化和持久化。
初始化和持久化
聚合根是一种特殊的实体，它有自己的属性和方法
聚合根可以实现聚合之间的对象引用，还可以引用聚合内的所有实体。
聚合根类放在代码模型的 Entity 目录结构下。聚合根有自己的实现方法，比如生成客户编码，新增和修改客户信息等方法。
2. 找出聚合根
根据需要将某些实体的某些属性或属性集设计为值对象
值对象类放在代码模型的 Entity目录结构下
在个人客户聚合中，客户拥有客户证件类型，它是以枚举值的形式存在，所以将它设计为值对象。
如果这个领域对象在其它聚合内维护生命周期，且在它依附的实体对象中只允许整体替换，我们就可以将它设计为值对象
如果这个对象是多条且需要基于它做查询统计，我建议将它设计为实体。
有些领域对象可以设计为值对象，也可以设计为实体，我们需要根据具体情况来分析
3. 设计值对象
如果领域模型中领域事件会触发下一步的业务操作，我们就需要设计领域事件
时机
首先确定领域事件发生在微服务内还是微服务之间
然后设计事件实体对象，事件的发布和订阅机制，以及事件的处理机制
判断是否需要引入事件总线或消息中间件
具体实现
在个人客户聚合中有客户已创建的领域事件，因此它有客户创建事件这个实体。
领域事件实体和处理类放在领域层的 Event 目录结构下
领域事件的发布和订阅类我建议放在应用层的 Event 目录结构下。
4. 设计领域事件
领域服务通过对多个实体和实体方法进行组合，完成核心业务逻辑
你可以认为领域服务是位于实体方法之上和应用服务之下的一层业务逻辑。
按照严格分层架构层的依赖关系，如果实体的方法需要暴露给应用层，它需要封装成领域服务后才可以被应用服务调
所以如果有的实体方法需要被前端应用调用，我们会将它封装成领域服务，然后再封装为应用服务。
使用
个人客户聚合根这个实体创建个人客户信息的方法，被封装为创建个人客户信息领域服务。
然后再被封装为创建个人客户信息应用服务，向前端应用暴露
领域服务类放在领域层的 Service 目录结构下。
目录位置
5. 设计领域服务
每一个聚合都有一个仓储，仓储主要用来完成数据查询和持久化操作
仓储包括仓储的接口和仓储实现，通过依赖倒置实现应用业务逻辑与数据库资源逻辑的解耦。
仓储代码放在领域层的 Repository 目录结构下
6. 设计仓储
下面我们就来看一下这些领域对象是怎么得来的？
领域层的领域对象
应用层的主要领域对象是应用服务和事件的发布以及订阅。
在事件风暴或领域故事分析时，我们往往会根据用户或系统发起的命令，来设计服务或实体方法
在应用层和领域层分别会发生哪些业务行为；
各层分别需要设计哪些服务或者方法；
这些方法和服务的分层以及领域类型（比如实体方法、领域服务和应用服务等），它们之间的调用和组合的依赖关系。
为了响应这个命令，我们需要分析和记录：
在严格分层架构模式下，不允许服务的跨层调用，每个服务只能调用它的下一层服务
服务从下到上依次为：实体方法、领域服务和应用服务。
如果需要实现服务的跨层调用，我们应该怎么办？
我建议你采用服务逐层封装的方式。
如果单一实体的方法需要被跨层调用，你可以将它封装成领域服务，这样封装的领域服务就可以被应用服务调用和编排了
如果它还需要被用户接口层调用，你还需要将这个领域服务封装成应用服务
实体方法是最底层的原子业务逻辑
经过逐层服务封装，实体方法就可以暴露给上面不同的层，实现跨层调用。
封装时服务前面的名字可以保持一致，你可以用 *DomainService 或 *AppService 后缀来区分领域服务或应用服务。
1. 实体方法的封装
领域服务会对多个实体和实体方法进行组合和编排，供应用服务调用
如果它需要暴露给用户接口层，领域服务就需要封装成应用服务。
2. 领域服务的组合和封装
应用服务会对多个领域服务进行组合和编排，暴露给用户接口层，供前端应用调用。
多个应用服务可能会对多个同样的领域服务重复进行同样业务逻辑的组合和编排。
当出现这种情况时，你就需要分析是不是领域服务可以整合了
你可以将这几个不断重复组合的领域服务，合并到一个领域服务中实现
这样既省去了应用服务的反复编排，也实现了服务的演进。
这样领域模型将会越来越精炼，更能适应业务的要求。
在应用服务组合和编排时，你需要关注一个现象
应用服务类放在应用层 Service 目录结构下。领域事件的发布和订阅类放在应用层 Event目录结构下。
3. 应用服务的组合和编排
应用层的领域对象
在完成上面的分析和设计后，我们就可以建立像下图一样的，领域对象与微服务代码对象的映射关系了。
个人客户领域模型中的个人客户聚合，就是典型的领域模型，从聚合内可以提取出多个实体和值对象以及它的聚合根。
定义领域对象位于分层架构中的哪一层
比如：接口层、应用层、领域层以及基础层等。
层
领域模型中领域对象的具体名称。
领域对象
根据 DDD 知识体系定义的领域对象的类型
包括：限界上下文、聚合、聚合根、实体、值对象、领域事件、应用服务、领域服务和仓储服务等领域类型
领域类型
根据业务对象依赖或分层调用的依赖关系，建立的领域对象的依赖关系
比如：服务调用依赖、关联对象聚合等。
依赖的领域对象
代码模型中的包名，对应领域对象所在的软件包。
包名
代码模型中的类名，对应领域对象的类名。
类名
代码模型中的方法名，对应领域对象实现或操作的方法名。
方法名
我们看一下上面这个图，我们对个人客户聚合做了进一步的分析
提取了个人客户表单这个聚合根，形成了客户类型值对象，以及电话、地址、银行账号等实体，为实体方法和服务做了封装和分层，建立了领域对象的关联和依赖关系，还有仓储等设计
关键是这个过程，我们建立了领域对象与微服务代码对象的映射关系。
提取思路
在建立这种映射关系后，我们就可以得到如下图的微服务代码结构了。
典型的领域模型
有些业务场景可能并不能如你所愿，你可能无法设计出典型的领域模型
这类业务中有多个实体，实体之间相互独立，是松耦合的关系，这些实体主要参与分析或者计算，你找不出聚合根，但就业务本身来说它们是高内聚的
而它们所组合的业务与其它聚合是在一个限界上下文内，你也不大可能将它单独设计为一个微服务。
比如，在个人客户领域模型内有客户归并的聚合，它扫描所有客户，按照身份证号码、电话号码等是否重复的业务规则，判断是否是重复的客户，然后对重复的客户进行归并。这种业务场景你就找不到聚合根。
我们还是可以借鉴聚合的思想，仍然用聚合来定义这部分功能，并采用与典型领域模型同样的分析方法，建立实体的属性和方法，对方法和服务进行封装和分层设计，设计仓储，建立领域对象之间的依赖关系
唯一可惜的就是我们依然找不到聚合根，不过也没关系，除了聚合根管理功能外，我们还可以用 DDD 的其它设计方法。
非典型领域模型
领域对象与微服务代码对象的映射
14 | 代码模型（下）：如何保证领域模型与代码模型的一致性？
在用 DDD 进行微服务设计时，我们可以通过事件风暴来确定领域模型边界，划定微服务边界
定义业务和系统运行边界，从而保证微服务的单一职责和随需而变的架构演进能力
微服务的设计要涉及到逻辑边界、物理边界和代码边界等等。
演进式架构就是以支持增量的、非破坏的变更作为第一原则，同时支持在应用程序结构层面的多维度变化
那如何判断微服务设计是否合理呢
随着业务的发展或需求的变更，在不断重新拆分或者组合成新的微服务的过程中
不会大幅增加软件开发和维护的成本，并且这个架构演进的过程是非常轻松、简单的。
其实很简单，只需要看它是否满足这样的情形就可以了
这也是微服务设计的重点，就是看微服务设计是否能够支持架构长期、轻松的演进
那用 DDD 方法设计的微服务，不仅可以通过限界上下文和聚合实现微服务内外的解耦
同时也可以很容易地实现业务功能积木式模块的重组和更新，从而实现架构演进。
演进式架构
有些项目团队在将集中式单体应用拆分为微服务时，首先进行的往往不是建立领域模型
而只是按照业务功能将原来单体应用的一个软件包拆分成多个所谓的“微服务”软件包
而这些“微服务”内的代码仍然是集中式三层架构的模式，“微服务”内的代码高度耦合，逻辑边界不清晰
当有一天你发现这些膨胀了的微服务，有一部分业务功能需要拆分出去，或者部分功能需要与其它微服务进行重组时
你会发现原来这些看似清晰的微服务，不知不觉已经摇身一变，变成了臃肿油腻的大单体了，而这个大单体内的代码依然是高度耦合且边界不清的
而随着新需求的提出和业务的发展，这些小单体微服务会慢慢膨胀起来
本质是边界问题
这种单体式微服务只定义了一个维度的边界，也就是微服务之间的物理边界，本质上还是单体架构模式。
微服务设计时要考虑的不仅仅只有这一个边界，别忘了还要定义好微服务内的逻辑边界和代码边界，这样才能得到你想要的结果
小单体微服务
微服务还是小单体？
DDD 设计方法里的限界上下文和聚合就是用来定义领域模型和微服务边界的。
在事件风暴中，我们会梳理出业务过程中的用户操作、事件以及外部依赖关系等，根据这些要素梳理出实体等领域对象
根据实体对象之间的业务关联性，将业务紧密相关的多个实体进行组合形成聚合，聚合之间是第一层边界
根据业务及语义边界等因素将一个或者多个聚合划定在一个限界上下文内，形成领域模型，限界上下文之间的边界是第二层边界。
DDD的设计过程
主要定义同一业务领域或应用内紧密关联的对象所组成的不同聚类的组合之间的边界
事件风暴对不同实体对象进行关联和聚类分析后，会产生多个聚合和限界上下文，它们一起组成这个领域的领域模型
微服务内聚合之间的边界就是逻辑边界
一般来说微服务会有一个以上的聚合，在开发过程中不同聚合的代码隔离在不同的聚合代码目录中
微服务的架构演进并不是随心所欲的，需要遵循一定的规则，这个规则就是逻辑边界
微服务架构演进时，在业务端以聚合为单位进行业务能力的重组，在微服务端以聚合的代码目录为单位进行微服务代码的重组
由于按照 DDD 方法设计的微服务逻辑边界清晰，业务高内聚，聚合之间代码松耦合，因此在领域模型和微服务代码重构时，我们就不需要花费太多的时间和精力了。
两个聚合分别内聚了各自不同的业务能力，聚合内的代码分别归到了不同的聚合目录下。
那随着业务的快速发展，如果某一个微服务遇到了高性能挑战，需要将部分业务能力独立出去，我们就可以以聚合为单位，将聚合代码拆分独立为一个新的微服务
这样就可以很容易地实现微服务的拆分。
我们也可以对多个微服务内有相似功能的聚合进行功能和代码重组，组合为新的聚合和微服务，独立为通用微服务
逻辑边界
主要从部署和运行的视角来定义微服务之间的边界
不同微服务部署位置和运行环境是相互物理隔离的，分别运行在不同的进程中
这种边界就是微服务之间的物理边界。
物理边界
主要用于微服务内的不同职能代码之间的隔离
微服务开发过程中会根据代码模型建立相应的代码目录，实现不同功能代码的隔离
代码边界可以控制代码重组的影响范围，避免业务和服务之间的相互影响
微服务如果需要进行功能重组，只需要以聚合代码为单位进行重组就可以了。
由于领域模型与代码模型的映射关系，代码边界直接体现出业务边界
代码边界
边界
微服务边界的作用
微服务的拆分可以参考领域模型，也可以参考聚合，因为聚合是可以拆分为微服务的最小单位的。
但实施过程是否一定要做到逻辑边界与物理边界一致性呢？也就是说聚合是否也一定要设计成微服务呢？
答案是不一定的，这里就涉及到微服务过度拆分的问题了。
比如：集成成本、发布成本、运维成本以及监控和定位问题的成本等。
在项目建设初期，如果你不具备较强的微服务管理能力，那就不宜将微服务拆分过细
当我们具备一定的能力以后，且微服务内部的逻辑和代码边界也很清晰，你就可以随时根据需要，拆分出新的微服务，实现微服务的架构演进了。
微服务的过度拆分会使软件维护成本上升
还要记住一点，微服务内聚合之间的服务调用和数据依赖需要符合高内聚松耦合的设计原则和开发规范，否则你也不能很快完成微服务的架构演进。
核心
正确理解微服务的边界
15 | 边界：微服务的各种边界在架构演进中的作用？
在 DDD 分层架构和微服务代码模型里，我们根据领域对象的属性和依赖关系，将领域对象进行分层，定义了与之对应的代码对象和代码目录结构
分层架构确定了微服务的总体架构，微服务内的主要对象有服务和实体等，它们一起协作完成业务逻辑
位于用户接口层，包括接口和实现两部分
用于处理用户发送的 Restful 请求和解析用户输入的配置文件等，并将数据传递给应用层
Facade服务
位于应用层。用来表述应用和用户行为
负责服务的组合、编排和转发，负责处理业务用例的执行顺序以及结果拼装，对外提供粗粒度的服务
应用服务
位于领域层。领域服务封装核心的业务逻辑，实现需要多个实体协作的核心领域逻辑
它对多个实体或方法的业务逻辑进行组合或编排，或者在严格分层架构中对实体方法进行封装，以领域服务的方式供应用层调用。
领域服务
位于基础层。提供基础资源服务（比如数据库、缓存等），实现各层的解耦，降低外部资源变化对业务应用逻辑的影响
基础服务主要为仓储服务，通过依赖倒置提供基础资源服务
领域服务和应用服务都可以调用仓储服务接口，通过仓储服务实现数据持久化。
基础服务
按照分层架构设计出来的微服务
1. 服务的类型
微服务架构下往往采用前后端分离的设计模式，前端应用独立部署
前端应用调用发布在API 网关上的 Facade 服务，Facade 定向到应用服务
此时领域服务会组装实体和实体方法，实现核心领域逻辑
领域服务通过仓储服务获取持久化数据对象，完成实体数据初始化。
第一种是应用服务调用并组装领域服务
这种方式主要针对像缓存、文件等类型的基础层数据访问
这类数据主要是查询操作，没有太多的领域逻辑，不经过领域层，不涉及数据库持久化对象。
第二种是应用服务直接调用仓储服务
应用服务作为服务组织和编排者，它的服务调用有这样两种路径：
微服务内跨层服务调用
微服务之间的应用服务可以直接访问，也可以通过 API 网关访问
由于跨微服务操作，在进行数据新增和修改操作时，你需关注分布式事务，保证数据的一致性。
微服务之间服务调用
领域事件驱动包括微服务内和微服务之间的事件（详见 [第 06 讲]）。
微服务内通过事件总线（EventBus）完成聚合之间的异步处理
微服务之间通过消息中间件完成。异步化的领域事件驱动机制是一种间接的服务访问方式。
当应用服务业务逻辑处理完成后，如果发生领域事件，可调用事件发布服务，完成事件发布。
发布
当接收到订阅的主题数据时，事件订阅服务会调用事件处理领域服务，完成进一步的业务操作。
订阅
领域事件驱动
微服务的服务调用包括三类主要场景
2. 服务的调用
微服务的服务是从领域层逐级向上封装、组合和暴露的。
基础层的服务形态主要是仓储服务
仓储接口服务供应用层或者领域层服务调用
仓储实现服务，完成领域对象的持久化或数据初始化。
仓储服务包括接口和实现两部分
领域层实现核心业务逻辑，负责表达领域模型业务概念、业务状态和业务规则
主要的服务形态有实体方法和领域服务。
实体采用充血模型，在实体类内部实现实体相关的所有业务逻辑，实现的形式是实体类中的方法。
实体是微服务的原子业务逻辑单元
在设计时我们主要考虑实体自身的属性和业务行为，实现领域模型的核心基础能力
不必过多考虑外部操作和业务流程，这样才能保证领域模型的稳定性。
尽量将业务逻辑归属到实体对象上，实在无法归属的部分则设计成领域服务
领域服务会对多个实体或实体方法进行组装和编排，实现跨多个实体的复杂核心业务逻辑。
对于严格分层架构，如果单个实体的方法需要对应用层暴露，则需要通过领域服务封装后才能暴露给应用服务。
DDD 提倡富领域模型
应用层用来表述应用和用户行为，负责服务的组合、编排和转发，负责处理业务用例的执行顺序以及结果的拼装
负责不同聚合之间的服务和数据协调，负责微服务之间的事件发布和订阅。
通过应用服务对外暴露微服务的内部功能，这样就可以隐藏领域层核心业务逻辑的复杂性以及内部实现机制
事件发布
订阅服务
主要的服务形态
除了完成服务的组合和编排外，应用服务内还可以完成安全认证、权限校验、初步的数据校验和分布式事务控制等功能。
为了实现微服务内聚合之间的解耦，聚合之间的服务调用和数据交互应通过应用服务来完成
原则上我们应该禁止聚合之间的领域服务直接调用和聚合之间的数据表关联
功能
用户接口层是服务前端应用之间服务访问和数据交换的桥梁
它处理前端发送的Restful 请求和解析用户输入的配置文件等，将数据传递给应用层
或获取应用服务的数据后，进行数据组装，向前端提供数据服务
主要服务形态是 Facade 服务
完成服务定向，DO 与 DTO 数据的转换和组装
实现前端与应用层数据的转换和交换。
Facade 服务分为接口和实现两个部分
服务形态
3. 服务的封装与组合
现在我们回顾一下 DDD 分层架构，分层架构有一个重要的原则就是：每层只能与位于其下方的层发生耦合。
在严格分层架构中，任何层只能与位于其直接下方的层发生依赖
在严格分层架构中，每一层服务只能向紧邻的上一层提供服务
虽然实体、实体方法和领域服务都在领域层，但实体和实体方法只能暴露给领域服务，领域服务只能暴露给应用服务。
这是因为通过封装你可以避免将核心业务逻辑的实现暴露给外部
将实体和方法封装成领域服务，也可以避免在应用层沉淀过多的本该属于领域层的核心业务逻辑，避免应用层变得臃肿
A 实体方法需封装成领域服务 aDomainService 才能暴露给应用服务aAppService
abDomainService 领域服务组合和封装 A 和 B 实体的方法后，暴露给应用服务 abAppService
还有就是当服务发生变更时，由于服务只被紧邻上层的服务调用和组合，你只需要逐级告知紧邻上层就可以了，服务可管理性比松散分层架构要好是一定的。
在松散分层架构中，任何层可以与其任意下方的层发生依赖。
在松散分层架构中，领域层的实体方法和领域服务可以直接暴露给应用层和用户接口层
松散分层架构的服务依赖关系，无需逐级封装，可以快速暴露给上层。
第一个是容易暴露领域层核心业务的实现逻辑
第二个是当实体方法或领域服务发生服务变更时，由于服务同时被多层服务调用和组合，不容易找出哪些上层服务调用和组合了它，不方便通知到所有的服务调用方。
松散分层架构
那根据耦合的紧密程度，分层架构可以分为两种
4. 两种分层架构的服务依赖关系
服务的协作
微服务内有哪些类型的数据对象？它们是如何协作和转换的？
微服务运行时的实体，是核心业务的载体。
领域对象 DO（Domain Object），
用于前端与应用层或者微服务之间的数据组装和传输，是应用之间数据传输的载体
数据传输对象 DTO（Data Transfer Object）
用于封装展示层指定页面或组件的数据。
视图对象 VO（View Object）
DO 数据需要持久化时，仓储服务会将 DO 转换为 PO 对象，完成数据库持久化操作
当 DO 数据需要初始化时，仓储服务从数据库获取数据形成 PO 对象，并将 PO 转换为 DO，完成数据初始化。
基础层的主要对象是 PO 对象。我们需要先建立 DO 和 PO 的映射关系
大多数情况下 PO 和 DO 是一一对应的。但也有 DO 和 PO 多对多的情况，在 DO 和 PO数据转换时，需要进行数据重组。
领域层的主要对象是 DO 对象
DO 是实体和值对象的数据和业务行为载体，承载着基础的核心业务逻辑
通过 DO 和 PO 转换，我们可以完成数据持久化和初始化。
如果需要调用其它微服务的应用服务，DO 会转换为DTO，完成跨微服务的数据组装和传输
用户接口层先完成 DTO 到 DO 的转换，然后应用服务接收 DO 进行业务处理
如果 DTO 与 DO 是一对多的关系，这时就需要进行 DO数据重组。
应用层的主要对象是 DO 对象
用户接口层会完成 DO 和 DTO 的互转，完成微服务与前端应用数据交互及转换
Facade服务会对多个 DO 对象进行组装，转换为 DTO 对象，向前端应用完成数据转换和传输。
前端应用主要是 VO 对象
前端应用
数据对象视图
16 | 视图：如何实现服务和数据在微服务各层的协作？
17 | 从后端到前端：微服务后，前端如何设计？
项目的目标是实现在线请假和考勤管理
目标
1.请假人填写请假单提交审批，根据请假人身份、请假类型和请假天数进行校验，根据审批规则逐级递交上级审批，逐级核批通过则完成审批，否则审批不通过退回申请人。
2. 根据考勤规则，核销请假数据后，对考勤数据进行校验，输出考勤统计。
功能描述如下
项目基本信息
战略设计是根据用户旅程分析，找出领域对象和聚合根
对实体和值对象进行聚类组成聚合，划分限界上下文，建立领域模型的过程。
战略设计采用的方法是事件风暴
采用的方法
产品愿景是对产品顶层价值设计，对产品目标用户、核心价值、差异化竞争点等信息达成一致，避免产品偏离方向。
所有参与者针对每一个要点，在贴纸上写出自己的意见，贴到白板上
事件风暴主持者会对每个贴纸，讨论并对发散的意见进行收敛和统一，形成下面的产品愿景图
事件风暴时
我们把这个产品愿景图整理成一段文字就是
为了满足内外部人员，他们的在线请假、自动考勤统计和外部人员管理的需求，我们建设这个在线请假考勤系统，它是一个在线请假平台，可以自动考勤统计
它可以同时支持内外网请假，同时管理内外部人员请假和定期考勤分析，而不像 HR 系统，只管理内部人员，且只能内网使用。
我们的产品内外网皆可使用，可实现内外部人员无差异管理
解释
通过产品愿景分析，项目团队统一了系统名称——在线请假考勤系统
明确了项目目标和关键功能，与竞品（HR）的关键差异以及自己的优势和核心竞争力等。
产品愿景分析的作用
产品愿景分析对于初创系统明确系统建设重点，统一团队建设目标和建立通用语言是很有价值的
但如果你的系统目标和需求非常清晰，这一步可以忽略。
项目团队成员一起用事件风暴分析请假和考勤的用户旅程
根据不同角色的旅程和场景分析，尽可能全面地梳理从前端操作到后端业务逻辑发生的所有操作、命令、领域事件以及外部依赖关系等信息。
用户：请假人
请假人登录系统：从权限微服务获取请假人信息和权限数据，完成登录认证。
创建请假单：打开请假页面，选择请假类型和起始时间，录入请假信息。保存并创建请假单，提交请假审批。
修改请假单：查询请假单，打开请假页面，修改请假单，提交请假审批。
提交审批：获取审批规则，根据审批规则，从人员组织关系中获取审批人，给请假单分配审批人
用户旅程
第一个场景：请假
第二个场景：审批
审批人登录系统：从权限微服务获取审批人信息和权限数据，完成登录认证。
获取请假单：获取审批人名下请假单，选择请假单。
审批：填写审批意见。
逐级审批：如果还需要上级审批，根据审批规则，从人员组织关系中获取审批人，给请假单分配审批人。重复以上 4 步。
最后审批人完成审批。
用户：审批人
完成审批后，产生请假审批已通过领域事件
发送请假审批已通过的通知，通知邮件系统告知请假人；
将请假数据发送到考勤以便核销
后续有两个进一步的业务操作
下面我就以请假和人员两个场景作为示例。
人员组织关系场景分析结果图
2. 场景分析
领域建模是通过对业务和问题域进行分析，建立领域模型
向上通过限界上下文指导微服务边界设计，向下通过聚合指导实体对象设计。
根据场景分析，分析并找出发起或产生这些命令或领域事件的实体和值对象
将与实体或值对象有关的命令和事件聚集到实体。
上面这个图是分析后的实体与命令的关系
通过分析，我们找到了：请假单、审批意见、审批规则、人员、组织关系、刷卡明细、考勤明细以及考勤统计等实体和值对象。
第一步找出领域实体和值对象等领域对象；
从上面的实体中，我们可以找出“请假单”和“人员”两个聚合根
我们发现审批意见、审批规则和请假单紧密关联，组织关系和人员紧密关联。
找出这些实体的关系后，我们发现还有刷卡明细、考勤明细和考勤统计，这几个实体没有聚合根
然后找出与聚合根紧密依赖的实体和值对象
刷卡明细、考勤明细和考勤统计这几个实体，它们之间相互独立，找不出聚合根，不是富领域模型，但它们一起完成考勤业务逻辑，具有很高的业务内聚性
我们将这几个业务关联紧密的实体，放在一个考勤聚合内。
在微服务设计时，我们依然采用 DDD 的设计和分析方法。
由于没有聚合根来管理聚合内的实体，我们可以用传统的方法来管理实体
定义聚合前，先找出聚合根
其中请假聚合有请假单、审批意见实体和审批规则等值对象
人员组织关系聚合有人员和组织关系等实体
考勤聚合有刷卡明细、考勤明细和考勤统计等实体。
经过分析，我们建立了请假、人员组织关系和考勤三个聚合
如图 所示
第二步找出聚合根，根据实体、值对象与聚合根的依赖关系，建立聚合；
由于人员组织关系聚合与请假聚合，共同完成请假的业务功能，两者在请假的限界上下文内
因此我们为业务划分请假和考勤统计两个限界上下文，建立请假和考勤两个领域模型。
第三步根据业务及语义边界等因素，定义限界上下文。
领域建模是一个收敛的过程，分三步
比如：职责单一性
非功能性需求（如弹性伸缩、版本发布频率和安全等要求）
软件包大小
团队沟通效率和技术异构等非业务要素。
理论上一个限界上下文就可以设计为一个微服务，但还需要综合考虑多种外部因素
因此根据限界上下文就可以拆分为请假和考勤两个微服务
其中请假微服务包含人员组织关系和请假两个聚合，考勤微服务包含考勤聚合。
在这个项目，我们划分微服务主要考虑职责单一性原则
4. 微服务的拆分
包括：产品愿景、场景分析、领域建模和微服务拆分等几个主要过程。
具体过程
领域专家、业务需求方、产品经理、架构师、项目经理、开发经理和测试经理。
参与人员
战术设计是根据领域模型进行微服务设计的过程
主要梳理微服务内的领域对象
确定它们在代码模型和分层架构中的位置
建立领域模型与微服务模型的映射关系，以及服务之间的依赖关系。
做什么
领域专家、产品经理、架构师、项目经理、开发经理和测试经理等。
建议参与人员
领域模型有很多领域对象，但是这些对象带有比较重的业务属性
要完成从领域模型到微服务的落地，还需要进一步的分析和设计
在事件风暴基础上，我们进一步细化领域对象以及它们的关系，补充事件风暴可能遗漏的业务和技术细节
我们分析微服务内应该有哪些服务？服务的分层？应用服务由哪些服务组合和编排完成？
领域服务包括哪些实体和实体方法？哪个实体是聚合根？实体有哪些属性和方法？
哪些对象应该设计为值对象等。
事件风暴的命令是外部的一些操作和业务行为，也是微服务对外提供的能力
它往往与微服务的应用服务或者领域服务对应。我们可以将命令作为服务识别和设计的起点
服务集合中的服务包括领域服务或其它微服务的应用服务。
根据命令设计应用服务，确定应用服务的功能，服务集合，组合和编排方式
这里需要注意：应用服务可能是由多个聚合的领域服务组合而成的。
根据应用服务功能要求设计领域服务，定义领域服务
根据领域服务的功能，确定领域服务内的实体以及功能。
设计实体基本属性和方法。
另外，我们还要考虑领域事件的异步化处理。
具体步骤
我以提交审批这个动作为例，来说明服务的识别和设计
根据请假类型和时长，查询请假审批规则，获取下一步审批人的角色。
根据审批角色从人员组织关系中查询下一审批人。
为请假单分配审批人，并将审批规则保存至请假单。
提交审批应用服务。
领域服务有查询审批规则、修改请假流程信息服务以及根据审批规则查询审批人服务，分别位于请假和人员组织关系聚合
请假单实体有修改请假流程信息方法，审批规则值对象有查询审批规则方法
人员实体有根据审批规则查询审批人方法
下图是我们分析出来的服务以及它们之间的依赖关系。
请假单经多级审核后，会产生多条审批意见，为了方便查询，我们可以将审批意见设计为实体。
请假审批通过后，会产生请假审批通过的领域事件，因此还会有请假事件实体
审批意见（记录审批人、审批状态和审批意见）
请假事件实体。
请假聚合有以下实体
在请假单聚合中，聚合根是请假单。
请假人和下一审批人数据来源于人员组织关系聚合中的人员实体，可设计为值对象
人员类型、请假类型和审批状态是枚举值类型，可设计为值对象
确定请假审批规则后，审批规则也可作为请假单的值对象
请假人
人员类型
请假类型
下一审批人
审批状态
审批规则
我们就可以画出请假聚合对象关系图了。
我们再来分析一下请假单聚合的值对象
在人员组织关系聚合中，我们可以建立人员之间的组织关系，通过组织关系类型找到上级审批领导
实体有组织关系（包括组织关系类型和上级审批领导）。其中组织关系类型（如项目经理、处长、总经理等）是值对象。
上级审批领导来源于人员聚合根，可设计为值对象
组织关系类型
上级审批领导
人员组织关系聚合将包含以下值对象
我们又可以画出人员组织关系聚合对象关系图了。
它的聚合根是人员
人员组织关系
聚合中的对象
确定各领域对象的属性后，我们就可以设计各领域对象在代码模型中的代码对象（包括代码对象的包名、类名和方法名），建立领域对象与代码对象的一一映射关系了
根据这种映射关系，相关人员可快速定位到业务逻辑所在的代码位置
在经过以上分析后，我们在微服务内就可以分析出如下图的对象清单。
微服务内的对象清单
通过分析，我们需要在应用层和领域层设计以下服务和方法。
提交审批的大体流程是：
服务的识别和设计
1. 分析微服务领域对象
根据 DDD 的代码模型和各领域对象所在的包、类和方法，我们可以定义出请假微服务的代码结构，设计代码对象。
应用服务、DTO 以及事件发布相关代码
在 LeaveApplicationService 类内实现与聚合相关的应用服务，在 LoginApplicationService 封装外部微服务认证和权限的应用服务。
如果应用服务逻辑复杂的话，一个应用服务就可以构建一个类，这样可以避免一个类的代码过于庞大，不利于维护
提醒
应用层包括
领域层包括一个或多个聚合的实体类、事件实体类、领域服务以及工厂、仓储相关代码
一个聚合对应一个聚合代码目录，聚合之间在代码上完全隔离，聚合之间通过应用层协调。
人员和请假代码都放在各自的聚合所在目录结构的代码包中
如果随着业务发展，人员相关功能需要从请假微服务中拆分出来，我们只需将人员聚合代码包稍加改造，独立部署，即可快速发布为人员微服务
到这里，微服务内的领域对象，分层以及依赖关系就梳理清晰了
请假微服务领域层包含请假和人员两个聚合
领域层代码结构
2. 设计微服务代码结构
战术设计包括以下两个阶段
在完成领域模型和微服务设计后，我们还需要对微服务进行详细的设计
主要设计以下内容：实体属性、数据库表和字段、实体与数据库表映射、服务参数规约及功能实现等
1. 详细设计
开发人员只需要按照详细的设计文档和功能要求，找到业务功能对应的代码位置，完成代码开发就可以了
代码开发完成后，开发人员要编写单元测试用例，基于挡板模拟依赖对象完成服务测试
2. 代码开发和测试
后续的工作
18 | 知识点串讲：基于DDD的微服务设计实例
在从单体向微服务演进时，演进策略大体分为两种：绞杀者策略和修缮者策略。
绞杀者策略是一种逐步剥离业务能力，用微服务逐步替代原有单体系统的策略
它对单体系统进行领域建模，根据领域边界，在单体系统之外，将新功能和部分业务能力独立出来，建设独立的微服务
新微服务与单体系统保持松耦合关系
关系
随着时间的推移，大部分单体系统的功能将被独立为微服务，这样就慢慢绞杀掉了原来的单体系统
绞杀者策略类似建筑拆迁，完成部分新建筑物后，然后拆除部分旧建筑物。
1. 绞杀者策略
修缮者策略是一种维持原有系统整体能力不变，逐步优化系统整体能力的策略
比如高性能要求的功能，代码质量不高或者版本发布频率不一致的功能等。
它是在现有系统的基础上，剥离影响整体业务的部分功能，独立为微服务
通过这些功能的剥离，我们就可以兼顾整体和局部，解决系统整体不协调的问题
修缮者策略类似古建筑修复，将存在问题的部分功能重建或者修复后，重新加入到原有的建筑中，保持建筑原貌和功能不变
一般人从外表感觉不到这个变化，但是建筑物质量却得到了很大的提升。
2. 修缮者策略
建设期间，原有单体系统照常运行，一般会停止开发新需求
而新系统则会组织新的项目团队，按照原有系统的功能域，重新做领域建模，开发新的微服务
在完成数据迁移后，进行新旧系统切换。
对于大型核心系统我一般不建议采用这种策略
这是因为系统重构后的不稳定性、大量未知的潜在技术风险和新的开发模式下项目团队磨合等不确定性因素
会导致项目实施难度大大增加。
3.其实还有第三种策略，就是另起炉灶，顾名思义就是将原有的系统推倒重做
微服务的演进策略
简单的业务领域，一个领域就是一个小的子域
在这个小的问题域内，领域建模过程相对简单，直接采用事件风暴的方法构建领域模型就可以了。
简单领域建模
对于复杂的业务领域，领域可能需要多级拆分后才能开始领域建模
领域拆分为子域，甚至子域还需要进一步拆分
比如：保险它需要拆分为承保、理赔、收付费和再保等子域
承保子域再拆分为投保、保单管理等子子域
复杂领域如果不做进一步细分，由于问题域太大，领域建模的工程量会非常浩大。
你不太容易通过事件风暴，完成一个很大的领域建模，即使勉强完成，效果也不一定好。
根据业务领域的特点，参考流程节点边界或功能聚合模块等边界因素。
结合领域专家和项目团队的讨论，将领域逐级分解为大小合适的子域，针对子域采用事件风暴，划分聚合和限界上下文，初步确定子域内的领域模型
第一步，拆分子域建立领域模型
梳理领域内所有子域的领域模型，对各子域领域模型进行微调
微调的过程重点考虑不同领域模型中聚合的重组
同步考虑领域模型和聚合的边界，服务以及事件之间的依赖关系，确定最终的领域模型。
第二步，领域模型微调
根据领域模型和微服务拆分原则，完成微服务的拆分和设计。
第三步，微服务的设计和拆分
对于复杂领域，我们可以分三步来完成领域建模和微服务设计。
复杂领域建模
1. 新建系统
如果我们面对的是一个单体遗留系统，只需要将部分功能独立为微服务，而其余仍为单体
整体保持不变，比如将面临性能瓶颈的模块拆分为微服务
我们只需要将这一特定功能，理解为一个简单子领域，参考简单领域建模的方式就可以了
在微服务设计中，我们还要考虑新老系统之间服务和业务的兼容，必要时可引入防腐层。
2. 单体遗留系统
不同场景下的领域建模策略
很多人在接触微服务后，但凡是系统，一概都想设计成微服务架构
其实有些业务场景，单体架构的开发成本会更低，开发效率更高，采用单体架构也不失为好的选择
同样，虽然DDD 很好，但有些传统设计方法在微服务设计时依然有它的用武之地
很多人在学会 DDD 后，可能会将其用在所有业务域，即全部使用 DDD 来设计
首先企业内要培养 DDD 的文化
其次对团队成员的设计和技术能力要求相对比较高
DDD 从战略设计到战术设计，是一个相对复杂的过程
在资源有限的情况下，应聚焦核心域，建议你先从富领域模型的核心域开始，而不必一下就在全业务域推开。
1. 所有的领域都用 DDD
不同的设计方法有它的适用环境，我们应选择它最擅长的场景
管理新建和修改数据非常有效
比如在修改订单数据时，它可以保证订单总金额与所有商品明细金额的一致
适用的场景
传统的设计方法，可能一条简单的 SQL 语句就可以很快地解决问题。
比如数据统计和分析，DDD 很多方法可能都用不上，或用得并不顺手，而传统的方法很容易就解决了。
而很多贫领域模型的业务
不适用的场景
我们应该选择最适合的方法，不只是 DDD 设计方法，当然还应该包括传统的设计方法
这里要以快速、高效解决实际问题为最佳，不要为做 DDD 而做 DDD。
2. 全部采用 DDD 战术设计方法
很多 DDD 初学者，学习 DDD 的主要目的，可能是为了开发微服务，因此更看重 DDD 的战术设计实现
殊不知 DDD 是一种从领域建模到微服务落地的全方位的解决方案。
战略设计时构建的领域模型，是微服务设计和开发的输入，它确定了微服务的边界、聚合、代码对象以及服务等关键领域对象
领域模型边界划分得清不清晰，领域对象定义得明不明确，会决定微服务的设计和开发质量
没有领域模型的输入，基于 DDD 的微服务的设计和开发将无从谈起
因此我们不仅要重视战术设计，更要重视战略设计。
3. 重战术设计而轻战略设计
具体项目实施时，要吸取 DDD 的核心设计思想和理念
结合具体的业务场景和团队技术特点，多种方法组合，灵活运用，用正确的方式解决实际问题
4. DDD 只适用于微服务
误区
DDD 使用的误区
微服务设计首先应建立领域模型，确定逻辑和物理边界以及领域对象后，然后才开始微服务的拆分和设计
而不是先定义数据模型和库表结构，也不是前端界面需要什么，就去调整核心领域逻辑代码。
第一条：要领域驱动设计，而不是数据驱动设计，也不是界面驱动设计。
微服务上线后其功能和代码也不是一成不变的
随着需求或设计变化，领域模型会迭代，微服务的代码也会分分合合
边界清晰的微服务，可快速实现微服务代码的重组。微服务内聚合之间的领域服务和数据库实体原则上应杜绝相互依赖
你可通过应用服务编排或者事件驱动，实现聚合之间的解耦，以便微服务的架构演进。
第二条：要边界清晰的微服务，而不是泥球小单体。
分层架构中各层职能定位清晰，且都只能与其下方的层发生依赖，也就是说只能从外层调用内层服务，内层通过封装、组合或编排对外逐层暴露，服务粒度也由细到粗
应用层负责服务的组合和编排，不应有太多的核心业务逻辑，领域层负责核心领域业务逻辑的实现
各层应各司其职，职责边界不要混乱。在服务演进时，应尽量将可复用的能力向下层沉淀。
第三条：要职能清晰的分层，而不是什么都放的大箩筐。
比如：集成成本、运维成本、监控和定位问题的成本
微服务过度拆分必然会带来软件维护成本的上升
企业在微服务转型过程中还需要有云计算、DevOps、自动化监控等能力
而一般企业很难在短时间内提升这些能力，如果项目团队没有这些能力，将很难 hold 住这些微服务。
如果在微服务设计之初按照 DDD 的战略设计方法，定义好了微服务内的逻辑边界，做好了架构的分层
其实我们不必拆分太多的微服务，即使是单体也未尝不可
随着技术积累和能力提升，当我们有了这些能力后，由于应用内有清晰的逻辑边界
我们可以随时轻松地重组出新的微服务，而这个过程不会花费太多的时间和精力。
注意
第四条：要做自己能 hold 住的微服务，而不是过度拆分的微服务。
微服务设计原则
基于领域模型进行拆分，围绕业务领域按职责单一性、功能完整性拆分。
1. 基于领域模型
识别领域模型中的业务需求变动频繁的功能，考虑业务变更频率与相关度，将业务需求变动较高和功能相对稳定的业务进行分离
这是因为需求的经常性变动必然会导致代码的频繁修改和版本发布，这种分离可以有效降低频繁变动的敏态业务对稳态业务的影响
2. 基于业务需求变化频率
因为性能要求高的功能可能会拖累其它功能，在资源要求上也会有区别
为了避免对整体性能和资源的影响，我们可以把在性能方面有较高要求的功能拆分出去。
识别领域模型中性能压力较大的功能
3. 基于应用性能
除非有意识地优化组织架构，否则微服务的拆分应尽量避免带来团队和组织架构的调整
避免由于功能的重新划分，而增加大量且不必要的团队之间的沟通成本。
拆分后的微服务项目团队规模保持在 10～12 人左右为宜。
4. 基于组织架构和团队规模
有特殊安全要求的功能，应从领域模型中拆分独立，避免相互影响。
5. 基于安全边界
领域模型中有些功能虽然在同一个业务域内，但在技术实现时可能会存在较大的差异，也就是说领域模型内部不同的功能存在技术异构的问题
由于业务场景或者技术条件的限制，有的可能用.NET，有的则是 Java，有的甚至大数据架构
对于这些存在技术异构的功能，可以考虑按照技术边界进行拆分。
6. 基于技术异构等因素
微服务拆分需要考虑哪些因素？
19 | 总结（一）：微服务设计和拆分要坚持哪些原则？
20 | 总结（二）：分布式架构关键设计10问
DDD实战课
职业：暂无
0 条评论
回复 删除
下一页
