DDD学习笔记

目录

DDD分层架构是什么？

领域层和应用层的区别是什么？

中台业务建模过程？

怎么抉择一个实体是不是聚合根？

操作数据库应该放到哪里？聚合根中应该包括哪些业务行为？

在设计过程中，对于一些复杂的流程细节没考虑到位，或者忽略了某个细节流程，而导致在程序落地过程中，发现原有的建模不够严谨，对于这种场景，有什么补救措施吗，或者如何避免这一问题的发生？

DDD从设计到落地的大概流程？

---

DDD分层架构是什么？

4层架构：由下往上，基础层 -> 领域层 -> 应用层 -> 用户接口层

 

领域层和应用层的区别是什么？

先从底下往上逐层讲，单个实体自身的方法就是实体本身的业务行为。多个实体可组成更复杂的业务动作，这个是领域服务，实体的方法和领域服务共同构成领域模型的基础业务能力，这个能力是原子的基础的，不太考虑外界的用户行为和流程。而应用服务是对这些基础的能力进行组合和编排，它组合和编排的服务可以是跨聚合的领域服务，主要体现组合后的业务能力，更面向前端的用户操作，属于比较粗粒度的服务，通过编排可以更灵活应对外部需求变化。

 

中台业务建模过程？

第一步：按照业务流程（通常适用于核心域）或者功能属性、集合（通常适用于通用域或支撑域），将业务域细分为多个中台，再根据功能属性或重要性归类到核心中台或通用中台。核心中台设计时要考虑核心竞争力，通用中台要站在企业高度考虑共享和复用能力。

第二步：选取中台，根据用例、业务场景或用户旅程完成事件风暴，找出实体、聚合和限界上下文。依次进行领域分解，建立领域模型。由于不同中台独立建模，某些领域对象或功能可能会重复出现在其它领域模型中，也有可能本该是同一个聚合的领域对象或功能，却分散在其它的中台里，这样会导致领域模型不完整或者业务不内聚。这里先不要着急，这一步我们只需要初步确定主领域模型就可以了，在第三步中我们还会提炼并重组这些领域对象。

第三步：以主领域模型为基础，扫描其它中台领域模型，检查并确定是否存在重复或者需要重组的领域对象、功能，提炼并重构主领域模型，完成最终的领域模型设计。

第四步：选择其它主领域模型重复第三步，直到所有主领域模型完成比对和重构。

第五步：基于领域模型完成微服务设计，完成系统落地。

划分核心中台要看你的企业核心竞争力是否在这个领域。

以保险举例：

 

怎么抉择一个实体是不是聚合根？

判断一个实体是否是聚合根，你可以结合以下内容进行分析。

是否有独立的生命周期？是否有全局唯一 ID ？是否可以创建或修改其他对象？是否有专门的模块来管理这个实体等。
       聚合根管理了聚合内所有实体和值对象的生命周期，我们通过聚合根就可以获取到聚合内所有实体和值对象等领域对象。一般来说，如果聚合根被删除了，那么被它引用的实体和值对象也就不会存在了。

 

操作数据库应该放到哪里？聚合根中应该包括哪些业务行为？

在聚合内部操作数据库都是通过调用仓储接口来实现的。

由于一个聚合内需要按照统一的业务规则来完成实体的数据变更，也就是说不可以随意修改某一个实体的数据表。为了统一这些数据更新的操作，会统一由聚合根来管理，所以操作数据库的方法一般都是放在聚合根的方法中。对于聚合内跨多个实体的业务逻辑，这部分功能可以由聚合根的方法来实现，也可以通过聚合内的领域服务来实现。
       但为了避免聚合根的业务逻辑过于复杂，避免聚合根类代码量过于庞大，我个人建议聚合根除了承担它的聚合管理职能外，只作为实体实现与聚合根自身行为相关的业务逻辑，而将跨多个实体的复杂领域逻辑统一放在领域服务中实现。因此在完成业务逻辑后，在操作数据库时可以通过聚合根方法或领域服务来完成，切勿在某个实体的方法中不受控制的去修改数据库中实体的数据。

 

在设计过程中，对于一些复杂的流程细节没考虑到位，或者忽略了某个细节流程，而导致在程序落地过程中，发现原有的建模不够严谨，对于这种场景，有什么补救措施吗，或者如何避免这一问题的发生？

这个可能需要分一下几类情况来处理。
        1、如果是聚合内实体的业务逻辑没考虑到，只需要修改对应实体内的属性或者方法即可。
        2、如何是聚合内实体之间的关系没考虑到，调整或新增领域服务，或者聚合根的方法即可。
        3、如果是在同一个限界上下文内的聚合之间的关系没考虑到，在应用层的应用服务中调整或新增即可。
        4、如果是聚合划分到了错误的限界上下文内，整体将聚合内所有对象和代码调整到合适的限界上下文即可，并重新建立新的限界上下文内聚合之间的关系。

 

DDD从设计到落地的大概流程？

先进行战略设计，再进行战术设计。

战略设计采用的方法是事件风暴，包括产品愿景、场景分析、领域建模、微服务拆分。

    领域建模又分为3步：

           1.根据场景分析，分析并找出发起或产生这些命令或领域事件的实体和值对象，将与实体或值对象有关的命令和事件聚集到实体

           2.找出聚合根，根据实体、值对象与聚合根的依赖关系，建立聚合；

           3.根据业务及语义边界等因素，定义限界上下文

   微服务拆分：理论上一个限界上下文就可以设计为一个微服务，但还需要综合考虑多种外部因素，比如：职责单一性、敏态与稳态业务分离、非功能性需求（如弹性伸缩、版本发布频率和安全等要求）、软件包大小、团队沟通效率和技术异构等非业务要素。

战术设计包括：

          1.根据命令设计应用服务，确定应用服务的功能，服务集合，组合和编排方式。服务集合中的服务包括领域服务或其它微服务的应用服务。

          2.根据应用服务功能要求设计领域服务，定义领域服务。这里需要注意：应用服务可能是由多个聚合的领域服务组合而成的。

          3.根据领域服务的功能，确定领域服务内的实体以及功能。设计实体基本属性和方法。