一种很变态但有效的DDD建模沟通方式

本文书接上回《这就是为什么你学不会DDD》，关注公众号（老肖想当外语大佬）获取信息：

1. 最新文章更新；
2. DDD框架源码（.NET、Java双平台）；
3. 加群畅聊，建模分析、技术实现交流；
4. 视频和直播在B站。

https://mp.weixin.qq.com/s/TJEtclwcJydiE58pjWpXXw

 

背景

前文说到，我们在建模的时候要放下技术层面的心智负担，这是我们自己内在的问题，相对来讲容易克服。但另外一面，我们分析需求、设计模型时候，就会与业务人员、产品经理等角色进行深入沟通互动，这个时候，很难找到一个比较一致的表述方式，以在大家的大脑中展现出比较一致的形象，往往会出现认知偏差，甚至相互得出相反的理解却无法察觉的情况，沟通效率和准确性非常糟糕。

为了解决这个问题，我们发现了一个很容易被接受的“类比”，就是“拟人化模型沟通法”。

PS： 你依然要先忘掉所有的技术知识。

 

为什么可以拟人化

我们先来看下面的图，展示了一家公司的组织架构：

 

如果我们把图中的结构不变，仅仅是把元素的名称进行替换，就能得到一个系统的结构图：

 

在这里我们得到如下的对应关系：

 

其中公司对应系统，部门对应模块，可以理解为层级或者分组，是比较自然的，接下来我们重点看看员工和模型为什么可以对应。

 

“人”与“模型”的共性

 

首先我们思考一下，企业中员工之间是怎么协作的，我觉得无外乎下面两种情形：

 

1. 真“手把手”教你做事；
2. 我做好我的事，然后通知你，你做好你的事；

 

类似下图：

 

如果一个任务需要员工A手把手教员工B做，那是不是意味着下面几个情况：

1. 员工B无法独立完成该任务；
2. 员工A对该任务最终负责，或者至少是AB共同负责；

 

如果两个员工的协作模式模式2，即“我做好我的事，然后通知你，你做好你的事”，是不是意味着：

1. 员工A和员工B各自有自己的职责；
2. 员工A和员工B通过“通知（事件）”来协作；

 

基于上述的逻辑，我们是不是可以得出下面的类比：

 

 

基于这样的类比，我们可以得出如下结论：

 

1. 如果一个任务需要模型A直接依赖（调用）模型B，说明它们无法独自完成任务；
2. 如果模型A和模型B仅通过事件协作，说明它们相互独立，职责边界清晰；

 

这个结论情形2是非常合理的，但如果我们遇到的是情形1，一个任务需要模型A和模型B共同的信息协作才能完成，我们一般认为有两个可选方案：

1. 合并模型A和模型B，把他们看作一个整体，在模型图上的表现，就是他们之间有实线相连，他们是一个聚合整体；
2. 创建模型C，来负责这个任务的解决，由模型A和模型B通过事件通知的方式把信息告诉模型C；

 

最终我们的模型都会是通过事件的方式协作，“人”与“模型”的共性大体如下：

 

1. “人”与“模型”都有自己的职责，负责解决特定的业务问题；
2. “人”与“模型”都拥有要履行自己职责所需要的信息；
3. “人”与“模型”都通过事件驱动来协作；

 

 

拟人化建模沟通法

 

基于上面的推导，我们可以把一个个“模型”看作是一个个人的名字，那么在我们沟通时，就会可以用拟人化的方式来表达业务流程，表达模型的职责，表达模型身上需要携带哪些信息，表达命令与事件：

 

1. 当“支付单”支付成功的时候，“订单”得把自己的支付状态设置成已支付；
2. 当“用户”注册成功的时候，得向“用户积分账户”里发5个积分；
3. “商品列表”要展示“商品信息”和“销售统计”的综合信息，还得支持各种纬度的搜索，性能还得跟得上；

 

通过拟人化的方式，我们可以在业务人员、产品经理、技术人员的大脑中构建比较一致的形象，这些形象对应着“职责”、“能力”和“边界”，从而我们可以在一个频道上推演这些“模型”的定义和分工协作，是否真的可以满足需求，至此，我们的团队获得了一个能力，就是“有效的建模沟通”，借助这个能力，我们就可以实现“需求-模型-代码”三者一致性的前半部分，即“需求-模型”的一致性：

 

 

 

后续

后续，我们会就“模型-代码”如何保持一致性展开剖析，敬请期待。

 

请关注公众号（老肖想当外语大佬）获取最新更新。