与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）属于资料类型的资源、目录式的种类性质对象，或者可以被其他原型反复使用的，如商品类目、支付方式、方法值对象等，使用浅蓝色表示。接下来，咱们使用四色建模法来分析领域模型，总共分为四大步：
-
建立时标原型：寻找需要追溯的事件，根据追溯事件寻找足迹
-
建立PPT原型：丰富模型，寻找时标原型周围的人/事/物，使它可以更好地描述业务概念
-
建立角色原型：进一步从中抽象出可以参与到不同流程中去的角色
-
建立描述原型：把一些信息用描述对象补足
这里咱们需要注意的是，整个过程会穿插着原型之间关系/核心交互的标注。
我们来看一幅电商DDD的四色图案例：
领域建模实际案例
如下图所示，这是财务领域模型和支付中心模型的一部分，这里只描述了业务系统是如何运作起来的，并没有涉及表的具体字段设计，全量的模型图因涉及敏感信息不作详细展示：
领域建模就是这么个建模，这里我提一些设计细节：
-
粉红色指的是时标原型，是核心业务产生的数据，基本上对应表设计
-
模型属性不需要体现表的审计字段，比如通用的ID、创建者、修改时间、软删除标识等，模型行为也只需要设计核心行为即可，那种约定俗成的CRUD方法就不需要写出来了，设计要懂得取舍
-
BC内模型除了依赖、聚合等等连线，可使用箭头连接模型之间的核心交互，跨BC之间的模型使用虚线箭头连接，这里我是结合了DCI建模法（D表示数据，C表示上下文、场景，I表示模型间的交互）
-
对于表示业务唯一的属性，我使用了加粗展示，再也不用跟别人费劲去解析这些模型是用什么维度去建的了
-
对于还没上线的属性变动（新增/修改），使用红色标记，因为领域模型图是指导我们业务开发的
-
限界上下文的划分是一种非常主观的边界划分，为了后续代码能够灵活调整，在Controller的URL设计里不需要加上限界上下文
领域模型图就像代码一样，需要我们长期去维护的，不是说做完设计就不去管了，这一点很重要，微服务负责人一定要有这个意识。
关于DCI建模和DCI架构我会继续深入研究，DCI这块就留到下次再分享叭~好了，这次的DDD领域建模实战课就到这里，你学会（fei）了吗？
参考：https://mp.weixin.qq.com/s/5z9gT8dWDLD08DtVM41ssw
