【死磕DDD】聊聊领域建模方法论

企业架构法

CBM 组件化业务模型

图中纵着的一个个其实就是子域和界限上下文，横着的可能是一些策略层、控制层和执行层，里面又有一项一项的内容，这些内容在我们领域设计里面可以对应到一个个聚合，那就有了很多聚合也有了很多子系统。
如果说聚合太细了，我们不可能写的那么细，那你也许就是一个个的微服务、一个个模块。

面向服务架构设计

SOA面向服务架构模型

SOA是一切以总线为基准，总线里要完成异步的消息队列、要完成同步的API调用、要完成服务的注册等等。
上面还可以插拔，像流程化的应用服务、第三方的接口、交互式的内容、信息管理、安全模块、建模功能等等，所有的功能都插拔在总线之上。这种情况就是一个以总线为基石，然后插拔各种各样的内容，相对来说我们可以很自由的进行业务的拆分，然后接到这个组件上就能互相沟通、互相通讯了。基于同样的一套标准，同样的一套沟通协议，来开发我们整个的IT架构。

这两种不管是CBM，还是SOA都是五年之前的了，有点淘汰了。
那么有没有稍微新一点的呢？稍微新的有以下三种。

用例分析法

简单来看其实就是用UML语言把客户的具体需求全部拆解下来，可以用架构师思维的立方体模型来画，也可以像上图中，上面是组件模型，左下角是一些标准的用例分析，右下角是四加一模型等等。
UML语言有很多很多不同的变种，很多种设计模型。

但上述三种模型基本上都和领域有关，但它不是专有的领域模型，后面有两种模型，它们只为领域而生，也是比较潮流的模型，一起看下。

四色建模法

还记得小时候玩过的一个游戏，一个同学一个纸条，然后分工，有的同学写谁，有的同学写在哪里，有的同学写什么时间，有的同学写做什么事，然后把它们组合起来就能讲一个小故事了。
四色建模法就是和这个游戏类似。

• 谁、哪里：PPT（Party/Place/Thing）对象
• 什么身份：角色（Role）对象
• 如何的：描述：（Description）对象
• 做什么：时标型（Moment-Interval）对象

如上图，加入我们是网上买东西，如下订单了，这时候会有订单、网银记录、包裹存根等等，这些记录都是一段时间内发生的行为，这就是第一个红色。

然后我们紧接着，就是谁、在哪里，比如说用户的账户就是“谁”，产生的订单的对象是图书，还有员工在看促销记录，“在哪里”就是地理位置，这些信息就是绿颜色的内容。

下一步就是黄色，黄颜色代表的是角色，比如角色是市场总监，这个员工它是市场总监，所以他要查询整个企业的促销记录，同时是配货人，所以他要发送一个包裹出去。

最后一步是蓝色，蓝色是一个描述，书有一个描述。
把这四个串联起来，就是四色分析法。
这里面一旦把一个很复杂的场景变成简单的描述，基本上实体和值对象就出来了，一般绿色和红色都会用实体或者聚合根描述，黄色和蓝色可以考虑用值对象，尤其是蓝色基本上都是值对象，黄色还可以在值对象和实体之间有一个考量。
这样一个方法比较简单，所以也比较适合与业务人员沟通，用这样一套语言把业务描述清楚，

Event Storming事件风暴

这是一个什么样的方法论呢？他要解决一个什么样的问题呢？
其实我们仔细想一想，如果整个领域你要拆分好，要建模好，其实问题很多，比如：

• 演进式架构和迭代式开发
• 微服务拆分和向前兼容
• 如何和产品业务人员沟通
• 有没有一个可以在喝茶聊天中完成微服务拆分的方法？

那么事件风暴就很好的解决了这些问题，它有以下特点：

• 不需要画一张图
• 没有Visio、Word和PPT
• 准备一打便利贴
• 全程嘴炮和贴纸小游戏，完成微服务模块拆分

下面我们以一个敏捷项目管理系统为例：

如上图，这里是微服务拆分的第一大步，最后切分成这样一个个的纵条，每个纵条其实就是一个微服务了。

当然还有第二大步：

把这些服务之间的关系梳理清楚，应该是同步调用？还是异步消息？需要提供什么样的方法进行沟通？每一个聚合与实体里面应该提供什么样的成员变量？把这些都聊清楚，架构就可以很方便的进行类图设计或者ER图设计。
整个事件风暴的过程当中，一直到拆分完所有服务，把所有服务的关联关系梳理完，这个过程不需要画图，只需要贴纸，但是后面的设计代码、进行系统部署的时候还是需要用到IT图、架构图的，这些图已经和我们产品经理、业务方没有关系了，但是全过程在有产品经理和业务方参与的当中，没有任何IT手段的参与，这才是我们事件风暴的亮点。