DDD领域驱动(四)——之领域建模

前边两篇,我们讲述为什么用DDD?DDD如何做好需求梳理?DDD如何在系统的层面拆分为粗细粒度合适微服务,以及微服务的架构划分。也就是我们经常说的自顶向下的拆分,现在我们将要做的功能具体拆分到具体的服务上了,也有了菱形架构、四边形架构等骨架,那么接下来就需要我们进行领域的建模了,也就是传统软件设计中的详细设计了。先看下,这个阶段的重要点:

好,先说一下,我们传统的软件详细设计都是怎么做的?ER图进行业务抽象建模,根据ER图进行数据设计,功能流程图、时序图,数据流图,类图、状态图等通过抽象分析设计表、流程、数据扭转、状态、抽象接口类方法等方面,进行详细设计,进而有了可以编码的“说明书”。

 

而DDD呢?其实一些进行分析抽象设计的方法是公用的,我一直觉得每种方式方法论都有其的优势与劣势,我们不要将其边界划分的太割裂,要善于取其精华去其糟粕。例如我认为流程图、时序图、思维导图等是非常好用的工具,在任何地方都可以去善于应用的。好,接下来我们看下DDD中领域建模几个核心点:

 


 

       一,实体(entity)、值对象(value object)

       实体:实体是我们统一语言中,根据现实生活、具体业务进行抽象的,具有唯一标识,可变性,具有生命周期等特性。而且DDD中的实体,经常会设计成充血模型(充血、贫血模型可参考《充血模型VS贫血模型》)。和现实对比一下:人(类)有手、脚、嘴、鼻子……(属性),可以拿东西、踢足球、吃饭、闻气味(方法能力),不像传统的类,只有get、set方法,而具体的功能方法都在业务类中。

       值对象:通过对象属性值来识别对象,它将多个相关属性组合为一个概念整体。其实就是在业务中用来传输一些属性值的合体。没有生命周期,不可变、不具有唯一标识等。

       举个例子:在用户下单购买物品时,订单就是一个实体,根据统一语言抽象为订单,具有唯一订单号,进行下单过程订单的某些属性会不停的改变,订单完成以后生命周期也就结束了,其中订单的各种变化,都已在实体中具有其对应的功能方法(充血);而在统计业务中,单笔订单就可以设计为值对象,主要是为了传输其属性值,值不可变,没有生命等。也就是实体和值对象不是绝对的,而且在不同的场景身份会进行相应的改变。

         最后,想聊下,为什么DDD推崇实体实现用充血模型呢?个人感觉是:更符合现实生活,更加容易理解。当然更重要的内聚更高,从而更易扩展,也就更易应对业务需求的变化了……

 


 

二,聚合(Aggregate)、聚合根(AggregateRoot)

        聚合(Aggregate),实体和值对象其实个体,就像现实生活一样,我们有个人有团体,而聚合就类似团体,而聚合根可以理解为其领导(或者和外边打交道的角色)。聚合其实就是为了某个业务,抽象的高内聚的边界。

 

如何设计聚合呢?

1,采用事件风暴;

2,从众多实体中选出适合作为对象管理者的根实体,也就是聚合根;

3,根据业务单一职责和高内聚原则,找出聚合根关联的所有紧密依赖的实体和值对象;

4,在聚合内根据聚合根、实体和值对象的依赖关系,画出对象的引用和依赖模型;

5,多个聚合根据业务语义和上下文一起划分到同一个限界上下文内;

 

聚合一些设计原则:

1,在一致性边界内建模真正的不变条件(抽象业务)

2,尽量小的聚合(善于管理、更容易应对变化)

3,通过唯一标识引用其他聚合(低耦合)

4,聚合之间使用最终一致性(领域事件-低耦合)

 

看下经常用的几种对象:

1,数据持久化对象 PO(PersistentObject),与数据库结构一一映射,是数据持久化过程中的数据载体。

2,领域对象 DO(DomainObject),微服务运行时的实体,是核心业务的载体。

3,数据传输对象 DTO(Data TransferObject),用于前端与应用层或者微服务之间的数据组装和传输,是应用之间数据传输的载体。

4,视图对象 VO(ViewObject),用于封装展示层指定页面或组件的数据。


 

三,领域服务、领域事件

领域服务:将抽象的业务进行封装实体、值对象、聚合等对外提供的服务Domain Service。

领域事件:领域之间的异步交互业务处理,我们常用的mq处理机制publish和 subscribe。


 

领域建模,就是在上篇的大的划分架构基础上,对具体的业务进行设计,抽象出实体、值对象,组合出聚合根,对外暴露出服务,设计出事件异步处理功能。从而是微服务达到有架构有肉的饱满的目的。进而完成微服务的实现。


 

其实在这里想说几点:1,抽象是核心;2,自顶向下的拆分是方法;3,高内聚低耦合是追求;4,易扩展、易复用,易维护是目的。

猜你喜欢

转载自blog.csdn.net/liujiahan629629/article/details/107528880