与DDD领域驱动设计相对的:数据驱动设计(直接画数据库类图)

DCI架构:总结成一句话就是:领域对象(Object)在不同的场景(Context)中扮演(Cast)不同的角色(Role),角色之间通过交互(Interactive)来完成具体的业务逻辑。

 

推荐两种比较常用的领域发现方法:事件风暴与四色建模法。

 

领域建模三步曲

对于不同的人提炼出来的领域模型不可能完全一致,这是因为每个人对业务理解的角度都不同。那么,怎么才能保证建模的正确性?

这听起来是个合理的质疑,但实际上却不是那么有道理。首先我们需要明白建模的目的是什么?如果仅仅是为了描画问题,那么并没有什么对错之分——仅仅是立场和角度的差别;而如果是为了企业业务系统而进行建模,那么这个问题应该变为:如何保证模型能够支撑企业的运营?

我给大家梳理以下几个步骤:

一、统一语言,梳理业务

在做设计的时候,梳理业务贯穿了整个过程。这需要技术与业务专家利用统一语言,描绘需求或问题本身,不断梳理业务,提炼出核心的领域模型(而非表设计)。

这有利于拉近技术人员与业务人员之间的关系,建立信任,达成统一的业务目标。

二、识别聚合、聚合根

梳理完业务后,找出实体、值对象,识别出各个聚合与聚合根。

如何识别聚合与聚合根?

一个Bounded Context(限界上下文)可能包含多个聚合,每个聚合都有一个根实体,叫做聚合根;

如何进行关联?

聚合根到聚合根:通过ID关联

聚合根到其内部的实体,直接对象引用;

聚合根到值对象,直接对象引用;

对于聚合,有以下设计原则:

聚合是用来封装真正的不变性,而不是简单的将对象组合在一起聚合应尽量设计的小,尽可能小的拆分,可以避免重构,重新拆分聚合之间的关联通过ID,而不是对象引用聚合内强一致性,聚合之间最终一致性应用层实现跨聚合的调用,避免跨聚合的领域服务调用和数据表关联。

三、划分限界上下文

第二步完成以后,我们根据不同的场景来划分限界上下文,以便进行微服务拆分。通过这种基于业务理解的拆分方式,我们的系统就能做到高内聚,做到单一职责,拆分出来的每个微服务都是软件变化的一个原因,不会因为某个原因发生的变更去修改每个微服务,“牵一发而动全身”。

 

 

 

DDD设计呈现之——四色建模

四色建模法是对领域模型的一种分析方法论,关注点是领域模型的归类,它是一种呈现方法。四色原型诞生于90年代,最先由Peter Coad和Mark Mayfield提出[Coad92],然后由David North拓展[Coad95-97],是一种被广泛使用的系统分析方法。使用四色建模法设计出来的四色图,它所表达的类图是一种包含顺序图的完全动态图,它是立体多维的,有异于完全静态的数据库ER图。那四色原型具体是哪四色呢?我们一起来看看:时标原型(Moment-Interval Archetype,简称MI)表示事物在某个时刻或某一段时间内发生的,如销售订单、客户账单、收款记录等,使用浅红色表示。PPT原型(Part-Place-Thing Archetype,人/事/物原型,简称PPT)表示参与扮演不同角色的人或事物,如商品、账户、店铺等,使用浅绿色表示。角色原型(Role Archetype,简称ROLE)抽象了一种参与方式,由人或组织机构、地点或物品来承担,如客户、商家、仓储团队、财务组织等,使用浅黄色表示。描述原型(Description Archetype,简称DESC)属于资料类型的资源、目录式的种类性质对象,或者可以被其他原型反复使用的,如商品类目、支付方式、方法值对象等,使用浅蓝色表示。接下来,咱们使用四色建模法来分析领域模型,总共分为四大步:

  1. 建立时标原型:寻找需要追溯的事件,根据追溯事件寻找足迹

  2. 建立PPT原型:丰富模型,寻找时标原型周围的人/事/物,使它可以更好地描述业务概念

  3. 建立角色原型:进一步从中抽象出可以参与到不同流程中去的角色

  4. 建立描述原型:把一些信息用描述对象补足

这里咱们需要注意的是,整个过程会穿插着原型之间关系/核心交互的标注。

我们来看一幅电商DDD的四色图案例:

 

 

领域建模实际案例

如下图所示,这是财务领域模型和支付中心模型的一部分,这里只描述了业务系统是如何运作起来的,并没有涉及表的具体字段设计,全量的模型图因涉及敏感信息不作详细展示:

 

 

 

 

领域建模就是这么个建模,这里我提一些设计细节:

  • 粉红色指的是时标原型,是核心业务产生的数据,基本上对应表设计

  • 模型属性不需要体现表的审计字段,比如通用的ID、创建者、修改时间、软删除标识等,模型行为也只需要设计核心行为即可,那种约定俗成的CRUD方法就不需要写出来了,设计要懂得取舍

  • BC内模型除了依赖、聚合等等连线,可使用箭头连接模型之间的核心交互,跨BC之间的模型使用虚线箭头连接,这里我是结合了DCI建模法(D表示数据,C表示上下文、场景,I表示模型间的交互)

  • 对于表示业务唯一的属性,我使用了加粗展示,再也不用跟别人费劲去解析这些模型是用什么维度去建的了

  • 对于还没上线的属性变动(新增/修改),使用红色标记,因为领域模型图是指导我们业务开发的

  • 限界上下文的划分是一种非常主观的边界划分,为了后续代码能够灵活调整,在Controller的URL设计里不需要加上限界上下文

领域模型图就像代码一样,需要我们长期去维护的,不是说做完设计就不去管了,这一点很重要,微服务负责人一定要有这个意识。

关于DCI建模和DCI架构我会继续深入研究,DCI这块就留到下次再分享叭~好了,这次的DDD领域建模实战课就到这里,你学会(fei)了吗?

 

参考:https://mp.weixin.qq.com/s/5z9gT8dWDLD08DtVM41ssw