中台架构与实现（基于DDD和微服务）-读书笔记3

第一部分 认识中台——微服务设计为什么要选择DDD

一、微服务拆分和设计的困境

       微服务的粒度应该如何把握？微服务到底应该如何拆分和设计？微服务的边界到底应该在哪里？

       微服务拆分困境产生的根本原因，就是不知道业务或应用的边界到底在什么地方。微服务设计第一步是先划分业务领域边界，然后在边界内构件业务领域模型，根据领域模型完成从单体应用到微服务的建设。

       DDD的核心思想是从业务视角出发，根据限界上下文边界划分业务的领域边界，定义领域模型，确定业务边界。

二、为什么DDD适合微服务

       DDD是一种处理高度复杂领域的设计思想，它试图分离技术实现的复杂性，并围绕业务概念构建领域模型来控制业务的复杂性，以解决软件难以理解，难以演进的问题。DDD不是架构，它是一种架构设计方法论，它通过业务边界划分将复杂业务领域简单化，划分出清晰的业务领域和应用边界，从而很容易实现微服务的架构演进。

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

• 战略设计：从业务视角出发，划分业务的领域边界，建立基于通用语言和业务上下文语义边界的限界上下文，构建领域模型。而限界上线文就可作为微服务拆分和设计的边界。
• 战术设计：从战术设计中会有聚合、聚合根、实体、值对象、领域服务、领域事件、应用服务和仓储等领域对象，这些领域对象会以代码的形式映射到微服务中，完成设计和系统落地。

2.2 DDD战略设计中的领域建模是发散到收敛过程，通常采用事件风暴工作坊方法

• 首先，针对业务领域，通过用例分析、场景分析和用户旅程分析等方法，尽可能全面地、不遗漏地梳理业务领域，发现这些业务领域中的命令、领域事件、领域对象以及它们的业务行为，并梳理这些领域对象之间的关系，这是一个发散的过程
• 然后，将事件风暴过程中提取的实体、值对象和聚合根等领域对象，从不同的维度进行聚类，形成如聚合和限界上下文等边界，并在限界上下文边界内建立领域模型，这是一个收敛的过程，收敛输出的结果就是领域模型。

2.3 三步构建领域模型和划分微服务边界

• 第一步，在事件风暴中根据场景分析，梳理业务过程中的用户操作、领域事件以及与外部的依赖关系等，找出哪些业务对象产生了这些业务操作或行为，并根据这些业务对象梳理出实体等领域对象。
• 第二步，根据领域实体之间的业务关联性，找出聚合根，将业务紧密相关的、相互依赖的实体组合形成聚合，确定聚合中的聚合根、值对象和实体。同一个限界上下文中，觉和之间的边界是微服务内部的第一层边界，这些聚合在同一个微服务实例内运行。这个边界是一个逻辑边界。
• 第三步，根据业务语义环境及上下文边界等因素，将一个或多个聚合划定在一个限界上下文内容，构建领域模型。限界上下文之间的边界是第二层边界，这一层边界可能就是未来微服务的边界。不同限界上下文内的领域模型的业务逻辑，被隔离在不同的微服务实例中运行，它们在物理上时相互隔离的，所以这一层边界是物理边界。

       在战略设计中我们建立了领域模型，划定了业务领域的边界，建立了通用语言和限界上下文，确定了领域模型中各个领域对象的依赖关系。到这，业务端领域模型的设计工作基本完成了，这个过程同时也基本确定了应用端的微服务边界。在领域模型向微服务落地过程中，即DDD从战略设计向战术设计的过程中，我们会将领域模型中的领域对象与代码模型中的代码对象建立映射关系，将业务架构和系统架构进行映射和绑定。党业务发生变化，我们需要为了响应业务变化而调整业务架构和领域模型时，系统架构也同时调整，并同步建立新的映射关系。

2.4 DDD与微服务关系

• DDD是一种架构设计方法，微服务是一种架构风格，两者从本质上都为了追求软件的高响应力，而从业务视角去分离应用系统建设复杂度的手段。两者都强调从业务领域出发，根据业务发展，合理划分业务领域边界，采用分治策略，降低业务和软件开发的复杂度，持续调整现有架构，优化现有代码，以保持脚骨和代码的生命力，即演进式架构。
• DDD作为一种通用的设计方法，它主要关注从业务领域视角划分领域边界，构建通用语言进行高效沟通，通过业务抽象，建立领域模型，维持业务和代码的逻辑一致性。而微服务作为领域模型的系统落地，它主要关注从领域模型到微服务的代码映射和落地，运行时的进程间通信、容错和故障隔离，实现去中心化的数据管理和服务治理，关注微服务的独立开发、测试、构建和部署。

第一部分 认识中台——DDD、中台和微服务的关系

       中台是抽象出来的业务模型，微服务是业务模型的系统实现，DDD作为方法论可同时指导中台业务建模和微服务建设，业务中台和微服务是DDD实战的最佳场景，三者相辅相成。

一、DDD和中台的本质

1.1 DDD的本质

       DDD按照一定的规则将业务领域进行细分，当领域被细分到一定程度后，DDD会将要解决的问题范围限定在特定边界内，并在这个边界内构件领域模型，进而用代码实现该领域模型，解决响应业务领域的应用建设问题。

       在领域细分过程中，可将领域分解为子域，子域还可继续分为子子域，一致到子域大小正好适合团队开展领域建模工作为止。当子域划分完成后，可根据子域自身的重要性和功能属性，经它们划分为三类不同的子域，即核心紫玉、支撑子域和通用子域。

1.2 中台的本质

       中台的本质是提炼各个业务板块的共同需求，进行业务和系统抽象，形成通用的、可复用的业务模型，打造成组件化产品，供前台部门使用。前台要做什么业务，需要什么资源，就可以直接找中台，而不需要每次都去改动自己的底层。

二、DDD、中台和微服务的协作

       企业聚焦在将通用能力和核心能力全部中泰华，以满足不同渠道核心业务能力的复用。企业将需要共享的公共能力进行领域建模，建设面向公共能力复用的通用能力中台。还会将核心能力进行领域建模，建设面向不同渠道的核心能力复用的核心能力中台。通用能力中台和核心能力中台都属于业务中台范畴。DDD将子域分为核心子域、通用子域和支撑子域，主要目的是通过识别企业重点领域，有区别地确定战略资源的投入。企业战略投入的重点是核心子域。

2.1 DDD视角和中台视角的领域分解过程

• 将企业所有的业务看作一个领域，在进行领域细分时，从DDD视角，子域可分为核心子域、通用子域和支撑子域。从中台建设视角，业务领域细分后的中台可分为核心中台和通用中台。
• 从领域功能属性和重要性对照来看：通用中台对应DDD的通用子域和支撑子域，实现企业可复用的通用业务能力；核心中台对应DDD的核心子域，实现企业的核心业务能力。
• 从领域的功能有范围看，子域与中台同属于业务子域，它们的功能边界是一致的。领域模型所在的界限上线文对应微服务，界限上线文可作为微服务拆分的依据。

       建立映射关系后，就可以用DDD来为中台构建领域模型了。

2.2 DDD、中台和微服务在中台设计过程中的协作方式

• DDD有一个重要原则，就是首先要建立通用语言的原则。在将DDD方法引入中台设时，首先需要建立中台和DDD的通过语言。DDD的核心子域、通用子域和支撑子域等子域与中台是一个层级的概念，不妨先将子域和中台这两个不同概念统称为中台。
• 在将业务领域划分为不同中台后，在中台这个子域内，可通过事件风暴，找出上下文界限，对中台进行进一步的设计和细分，然后根据界限上线文最终完成业务领域建模，构建出中台领域模型。由于不同中台业务领域的功能不同，界限上下文的数量和大小会不一样，领域模型也会不一样。
• 当完成业务建模后，就可将领域模型作为微服务设计的输入、采用DDD技术设计和DDD分层架构建模，设计聚合、实体、值对象、领域事件、领域服务及应用服务等领域对象，完成微服务的设计和开发。

三、如何完成中台业务建模

       中台业务抽象过程就是业务建模过程，对应DDD的战略设计。中台系统抽象的过程是微服务设计过程，对应DDD的战术设计。采用DDD方法的中台领域建模大致分为以下五个步骤：

• 第一步，按照核心业务流程节点（通常适用于核心子域）或者功能属性和集合（通常适用于通用子域或支撑子域），将业务领域细分为多个中台，再根据中台功能属性和重要性归类到核心中台和通用中台。核心中台设计时要考虑企业战略发展和核心竞争力以及多渠道核心能力复用，通用中台要站在企业高度进行抽象和标准化设计，面向所有业务领域实现能力共享和复用。
• 第二部，选取中台所在的业务领域，运营事件风暴方法，通过用例分析、业务场景分析或用户旅程分析等方法，找出业务领域的实体、聚合和限界上下文。依次完成各个中台的领域分解和领域建模。
• 第三部，在确定主题领域模型后，以主题域模型为基准，逐一扫描其他中台领域模型，根据名称或业务动作的相似性等条件，检查是否存在重复的领域模型或领域对象，或游离于主领域模型之外，但与主领域模型同属于一个限界上线文的领域对象。将这些重复或游离的领域对象，合并到主领域模型，提炼并重构主领域模型，完成领域模型设计。
• 第四部，选择其他领域模型重复第三步，直到所有领域模型完成领域对象比对和领域逻辑重构。
• 第五步，将领域模型作为微服务设计的额摄入，完成微服务的拆分和设计，完成微服务落地。

       综上，DDD战略设计涵盖了第一步到第四步，主要包括：将业务领域分解为不同属性的中台，将中台区分为核心中台和通用中台，在中台这个业务边界内完成领域建模，构建中台业务模型。DDD战术设计主要在第五步，将领域模型作为微服务设计的输入，映射到微服务就完成了中台的系统落地了。