4.中台领域建模

1.事件风暴构建领域模型

事件风暴

• 事件风暴是DDD战略设计中经常使用的一种方法，它可以快速分析和分解复杂的业务领域，分析并提取出领域对象，构建聚合，划分限界上下文边界，对业务进行抽象和归纳，完成领域建模；
• 事件风暴是一项团队活动，领域专家与项目团队通过头脑风暴的形式，罗列出领域中所有的领域事件，整合之后形成最终的领域事件集合。然后，为每一个事件标注出-导致该事件的命令，再为每一个事件标注出命令发起方的角色。命令可以是用户发起，也可以是第三方系统调用或者定时器触发等。最后对事件进行分类，整理出实体、聚合、聚合根以及限界上下文等，在限界上下文边界内构建领域模型；
• 事件风暴过程也是建立团队通用语言的过程，这个过程对于项目团队确定项目建设目标、完成业务领域模型分析、系统建设和落地非常重要；

概述

• 参与者
  领域专家，事件风暴的其他参与者可以是DDD专家、架构师、产品经理、项目经理、开发人员和测试人员等项目团队成员；
• 准备的材料
• 事件风暴的场地
• 事件风暴的关注点
  某些业务动作或行为(事件)是否会触发下一个业务动作，这个动作(领域事件)的输人和输出是什么？是谁(实体)发出的什么动作(命令)，触发了这个动作(事件)等；

事件风暴进行领域建模的过程

领域建模的关键过程主要包括: 产品愿景分析、场景分析、领域建模、微服务拆分与设计等几个重要阶段；

A.产品愿景分析

产品愿景分析的主要目标是完成产品顶层价值设计和分析，项目团队在目标用户、核心价值、产品需要具备的核心竞争力等方面达成一致，避免在建设过程中偏离方向；

B.场景分析

场景分析是从用户操作视角出发，根据业务流程或用户流程，采用用例和场景分析方法，探索领域中的典型场景，找出领域事件、实体和命令等领域对象，支撑领域建模的过程；

C.领域建模

领域建模时，我们会根据场景分析过程中产生的领域对象。构建完领域模型后，我们可以利用限界上下文向上指导微服务设计，也可以通过聚合向下指导聚合根、实体和值对象等的设计；
领域建模的具体过程可以分为以下四步:

• 第一步，提取领域对象；
  从命令和领域事件中提取产生这些业务行为的业务对象，即实体；
• 第二步，构建聚台；
  根据聚合根的管理性质，找出聚合根引用的实体和值对象，构建聚合；
• 第三步，划定限界上下文；
  根据业务上下文语义环境，将第二步产生的聚合归类，划定业务领域所在的限界上下文边界；
• 第四步，建立领域模型上下文服务地图；
  找出领域模型之间的服务依赖关系，分析并截断领域模型之间可能存在的循环依赖关系。限界上下文之间的服务关联应该是一种有向无环网状依赖关系；

D.服务拆分与设计

• 原则上，一个限界上下文内的领域模型就可以设计为一个微服务，它是作为微服务拆分的一个非常重要的依据；
• 微服务设计时，要考虑服务粒度、分层、边界划分、依赖关系和集成关系；
• 还需要考虑将敏态与稳态业务分离、非功能性需求(如弹性伸缩、安全性等要求)、团队组织和沟通效率、软件包大小以及技术异构等非业务因素；

2.构建中台业务模型

自顶向下的策略

• 这种策略是先做顶层设计，从最高级领域逐级分解为不同的子域，即中台，分别构建领域模型，根据领域属性和重要性将中台分为通用中台或核心中台；
• 自顶向下的领域建模过程主要基于业务现状和企业未来战略目标，不过多考虑系统建设现状。所以它比较适合全新的应用系统建设，或遗留系统推倒重建的建设模式；

步骤

主要分为三个关键步骤:

• 第一步，根据核心业务流程或功能边界，将领域分解为不同子域，子域根据不同的属性可以分为核心子域、通用子域和支撑子域；
• 第二步，对子域建模，划分限界上下文边界，建立领域模型；
• 第三步，根据限界上下文边界完成微服务拆分；

自底向上的策赂

• 这种策略基于业务和系统建设现状来重构中台领域模型。自底向上策略在领域建模时，将系统所在业务领域的公共利重复建设的业务能力沉淀到中台，进行抽象和标准化处理后，完成领域模型重构；
• 自底向上策略比较适合遗留系统领域模型的演进式重构、因此也适合单体应用向微服务架构演进；

步骤

主要分为三个关键步骤:

• 第一步,锁定业务领域,构建领域模型；
  将存在于不同领域模型中的重复的业务能力进行重构和抽象后，沉淀到中台业务模型。将分散的领域对象整合到统一的中台领域模型中，构建企业级的中台领域模型，提供可复用的中台服务；
• 第二步，对准基准域，重构中台领域模型；
  自底向上中台业务模型构建的过程，总结成一句话就是: 分域建模型，找准基准域，划分上下文，聚合重归类；
• 第三步，中台归类，完成微服务设计；

3.微服务的架构演进

演进式架构

• 微服务设计的重点: 随着业务的发展或需求变更，在领域模型和微服务不断被重新拆分，或者组合成新的微服务过程中。不会大幅增加软件开发和维护的成本，并且这个架构演进的过程是非常轻松和简单的；
• 微服务设计是否合理，关键要看它能否支持微服务架构的长期、轻松的演进；
• 用DDD方法设计的微服务，不仅可以通过限界上下文和聚合，实现微服务内外的解耦。同时也可以很容易地实现微服务积木式模块化的重组，支持微服务的架构演进；

微服务边界

• 逻辑边界: 微服务内聚合之间的边界是逻辑边界。它是一个虚拟的边界，强调业务的内聚性，可根据需要拆分为物理边界。也就是说聚合也可以独立为微服务，但不建议过度拆分；
• 物理边界: 微服务之间的边界是物理边界。它强调微服务部署和运行的隔离，关注微服务的服务调用、容错和运行等；
• 代码边界: 不同层或者聚合之间代码日录的边界是代码边界。它强调的是不同职责代码之间的隔离，方便架构演进时代码的重组和不同层的解耦。
• 通过定义上述边界，我们可以实现业务的高内聚和代码的松耦合。清晰的边界，可以快速实现微服务代码的重组，轻松实现微服务的架构演进；

总结

微服务设计和开发时，要时时刻刻想着微服务的架构演进，与生俱来就需要考虑聚合的解辗利未来聚合的重组，做到未雨绸缨；

4.DDD微服务设计

• DDD战略设计: 从事件风暴开始，提取实体和值对象等领域对象，找出聚合根构建聚合，划分限界上下文，最后建立领域模型；
• DDD战术设计: 将领域模型作为微服务设计的输入。识别和设计服务，建立各层服务的依赖关系。设计微服务内的实体和值对象，找出微服务巾所有的领域对象。建立领域对象与代码对象的映射关系；