本文为博主自学笔记整理，内容来源于互联网，如有侵权，请联系删除。
01 | 背景
微服务设计和拆分的困境
在微服务实践过程中经常会产生不少的争论和疑惑：
-
微服务的粒度应该多大呀？
-
微服务到底应该如何拆分和设计呢？
-
微服务的边界应该在哪里？
综合来看，微服务拆分困境产生的根本原因其实就是不知道业务或者微服务的边界到底在什么地方。
本篇主要讲解 DDD 的核心知识体系，具体包括：领域、子域、核心域、通用域、支撑域、限界上下文、实体、值对象、聚合和聚合根等概念。
02 | 领域、子域、核心域、通用域和支撑域
领域和子域
在研究和解决业务问题时，DDD 会按照一定的规则将业务领域进行细分，当领域细分到一定的程度后，DDD 会将问题范围限定在特定的边界内，在这个边界内建立领域模型。
领域可以进一步划分为子领域，称为子域，每个子域对应一个更小的问题域或更小的业务范围。
DDD 的研究方法与自然科学的研究方法类似。当人们在自然科学研究中遇到复杂问题时，通常的做法就是将问题一步一步地细分，再针对细分出来的问题域，逐个深入研究，探索和建立所有子域的知识体系。当所有问题子域完成研究时，我们就建立了全部领域的完整知识体系了。
上面这张图是在讲如何给桃树建立一个完整的生物学知识体系。初中生物课其实早就告诉我们研究方法了。它的研究过程是这样的。
第一步：确定研究对象，即研究领域，这里是一棵桃树。
第二步：对研究对象进行细分，将桃树细分为器官。
第三步：对器官进行细分，将器官细分为组织。。
第四步：对组织进行细分，将组织细分为细胞，细胞成为我们研究的最小单元。细胞之间的细胞壁确定了单元的边界，也确定了研究的最小边界。
核心域、通用域和支撑域
子域可以根据自身重要性和功能属性划分为三类，它们分别是：核心域、通用域和支撑域。
- 决定产品和公司核心竞争力的子域是核心域。
- 没有太多个性化的诉求，同时被多个子域使用的是通用域。
- 既不包含决定产品和公司核心竞争力的功能，也不包含通用功能的子域，它就是支撑域。
举例来说，通用域是你需要用到的通用系统，比如认证、权限等等，这类应用很容易买到，没有企业特点限制，不需要做太多的定制化。而支撑域则具有企业特性，但不具有通用性，例如数据代码类的数据字典等系统。
那为什么要划分核心域、通用域和支撑域，主要目的是什么呢？
公司在 IT 系统建设过程中，由于预算和资源有限，对不同类型的子域应有不同的关注度和资源投入策略。
03 | 限界上下文：定义领域边界的利器
在 DDD 领域建模和系统建设过程中，有很多的参与者，包括领域专家、产品经理、项目经理、架构师、开发经理和测试经理等。
对同样的领域知识，不同的参与角色可能会有不同的理解，那大家交流起来就会有障碍，怎么办呢？因此，在 DDD 中就出现了“通用语言”和“限界上下文”这两个重要的概念。
什么是通用语言？
在事件风暴过程中，通过团队交流达成共识的，能够简单、清晰、准确描述业务涵义和规则的语言就是通用语言。
也就是说，通用语言是团队统一的语言，不管你在团队中承担什么角色，在同一个领域的软件生命周期里都使用统一的语言进行交流。
下面是一个微服务设计实例的部分数据，表格中的这些名词术语就是项目团队在事件风暴过程中达成一致、可用于团队内部交流的通用语言。
什么是限界上下文？
我们知道语言都有它的语义环境，同样，通用语言也有它的上下文环境。为了避免同样的概念或语义在不同的上下文环境中产生歧义，DDD 在战略设计上提出了“限界上下文”这个概念，用来确定语义所在的领域边界。
我们可以将限界上下文拆解为两个词：限界和上下文。限界就是领域的边界，而上下文则是语义环境。通过领域的限界上下文，我们就可以在统一的领域边界内用统一的语言进行交流。
进一步理解限界上下文
正如电商领域的商品一样，商品在不同的阶段有不同的术语，在销售阶段是商品，而在运输阶段则变成了货物。同样的一个东西，由于业务领域的不同，赋予了这些术语不同的涵义和职责边界，这个边界就可能会成为未来微服务设计的边界。
看到这，我想你应该非常清楚了，领域边界就是通过限界上下文来定义的。
限界上下文和微服务的关系
车险承保的流程包含了投保、缴费、出单等几个主要流程。如果出险了还会有报案、查勘、定损、理算等理赔流程。
子域可能会包含多个限界上下文，如理赔子域就包括报案、查勘和定损等多个限界上下文。也有可能子域本身的边界就是限界上下文边界，如投保子域。
理论上限界上下文就是微服务的边界。我们将限界上下文内的领域模型映射到微服务，就完成了从问题域到软件的解决方案。
04 | 实体和值对象：领域模型的基础单元
实体
- 实体的业务形态：在战略设计时，实体是领域模型的一个重要对象。领域模型中的实体是多个属性、操作或行为的载体。
- 实体的代码形态：在代码模型中，实体的表现形式是实体类，这个类包含了实体的属性和方法，通过这些方法实现实体自身的业务逻辑。
- 实体的运行形态：实体以 DO（领域对象）的形式存在，每个实体对象都有唯一的 ID。我们可以对一个实体对象进行多次修改，修改后的数据和原来的数据可能会大不相同。但是，由于它们拥有相同的 ID，它们依然是同一个实体。
- 实体的数据库形态：在领域模型映射到数据模型时，一个实体可能对应 0 个、1 个或者多个数据库持久化对象。大多数情况下实体与持久化对象是一对一。在某些场景中，有些实体只是暂驻静态内存的一个运行态实体，它不需要持久化。
值对象
值对象是 DDD 领域模型中的一个基础对象，它跟实体一样，都包含了若干个属性，它与实体一起构成聚合。
如上图所示。我们可以将“省、市、县和街道等属性”拿出来构成一个“地址属性集合”，这个集合就是值对象。
- 值对象的业务形态。
本质上，实体是看得到、摸得着的实实在在的业务对象，实体具有业务属性、业务行为和业务逻辑。而值对象只是若干个属性的集合。
- 值对象的代码形态。
我们看一下下面这段代码，person 这个实体有若干个单一属性的值对象，比如 Id、name 等属性；同时它也包含多个属性的值对象，比如地址 address。
- 值对象的运行形态。
实体实例化后的 DO 对象的业务属性和业务行为非常丰富，但值对象实例化的对象则相对简单。
值对象嵌入到实体的话，有这样两种不同的数据格式，也可以说是两种方式，分别是属性嵌入的方式和序列化大对象的方式。
- 值对象的数据库形态。
在领域建模时，我们可以将部分对象设计为值对象，保留对象的业务涵义，同时又减少了实体的数量；在数据建模时，我们可以将值对象嵌入实体，减少实体表的数量，简化数据库设计。
- 值对象的优势和局限。
值对象采用序列化大对象的方法简化了数据库设计，减少了实体表的数量，可以简单、清晰地表达业务概念。这种设计方式虽然降低了数据库设计的复杂度，但却无法满足基于值对象的快速查询，会导致搜索值对象属性值变得异常困难。
实体和值对象的关系
DDD 提倡从领域模型设计出发，而不是先设计数据模型。
传统的数据模型设计通常是一个表对应一个实体，一个主表关联多个从表，当实体表太多的时候就很容易陷入无穷无尽的复杂的数据库设计，领域模型就很容易被数据模型绑架。可以说，值对象的诞生，在一定程度上，和实体是互补的。
有些场景中，地址会被某一实体引用，它只承担描述实体的作用，并且它的值只能整体替换，这时候你就可以将地址设计为值对象，比如收货地址。而在某些业务场景中，地址会被经常修改，地址是作为一个独立对象存在的，这时候它应该设计为实体，比如行政区划中的地址信息维护。
05 | 聚合和聚合根：怎样设计聚合？
聚合
领域模型内的实体和值对象就好比个体，而能让实体和值对象协同工作的组织就是聚合，它用来确保这些领域对象在实现共同的业务逻辑时，能保证数据的一致性。
领域服务和应用服务的区别？
聚合根
如果把聚合比作组织，那聚合根就是这个组织的负责人。聚合根也称为根实体，它不仅是实体，还是聚合的管理者。
在聚合之间，通过聚合根 ID 关联引用，如果需要访问其它聚合的实体，就要先访问聚合根，再导航到聚合内部实体，外部对象不能直接访问聚合内实体。
怎样设计聚合？
以保险的投保业务场景为例。
第 1 步：采用事件风暴，梳理出在投保过程中发生这些行为的所有的实体和值对象，比如投保单、标的、客户、被保人等等。
第 2 步：从众多实体中选出适合作为对象管理者的根实体，也就是聚合根。
判断一个实体是否是聚合根，你可以结合以下场景分析：是否有独立的生命周期？是否有全局唯一 ID？是否可以创建或修改其它对象？是否有专门的模块来管这个实体。
第 3 步：根据业务单一职责和高内聚原则，找出与聚合根关联的所有紧密依赖的实体和值对象。构建出 1 个包含聚合根（唯一）、多个实体和值对象的对象集合，这个集合就是聚合。
第 4 步：在聚合内根据聚合根、实体和值对象的依赖关系，画出对象的引用和依赖模型。
这里我需要说明一下：投保人和被保人的数据，是通过关联客户 ID 从客户聚合中获取的，在投保聚合里它们是投保单的值对象，这些值对象的数据是客户的冗余数据，即使未来客户聚合的数据发生了变更，也不会影响投保单的值对象数据。从图中我们还可以看出实体之间的引用关系，比如在投保聚合里投保单聚合根引用了报价单实体，报价单实体则引用了报价规则子实体。
第 5 步：多个聚合根据业务语义和上下文一起划分到同一个限界上下文内。
聚合的一些设计原则
- 聚合用来封装真正的不变性，而不是简单地将对象组合在一起。
- 设计小聚合。小聚合设计则可以降低由于业务过大导致聚合重构的可能性，让领域模型更能适应业务的变化。
- 通过唯一标识引用其它聚合。聚合之间是通过关联外部聚合根 ID 的方式引用，而不是直接对象引用的方式。
- 在边界之外使用最终一致性。聚合内数据强一致性，而聚合之间数据最终一致性。
- 通过应用层实现跨聚合的服务调用。应避免跨聚合的领域服务调用和跨聚合的数据库表关联。
在系统设计过程时，适合自己的才是最好的，一切以解决实际问题为出发点。
