本文书接上回《这就是为什么你学不会DDD》,关注公众号(老肖想当外语大佬)获取信息:
- 最新文章更新;
- DDD框架源码(.NET、Java双平台);
- 加群畅聊,建模分析、技术实现交流;
- 视频和直播在B站。
https://mp.weixin.qq.com/s/TJEtclwcJydiE58pjWpXXw
背景
前文说到,我们在建模的时候要放下技术层面的心智负担,这是我们自己内在的问题,相对来讲容易克服。但另外一面,我们分析需求、设计模型时候,就会与业务人员、产品经理等角色进行深入沟通互动,这个时候,很难找到一个比较一致的表述方式,以在大家的大脑中展现出比较一致的形象,往往会出现认知偏差,甚至相互得出相反的理解却无法察觉的情况,沟通效率和准确性非常糟糕。
为了解决这个问题,我们发现了一个很容易被接受的"类比 ",就是"拟人化模型沟通法"。
PS: 你依然要先忘掉所有的技术知识。
为什么可以拟人化
我们先来看下面的图,展示了一家公司的组织架构:
如果我们把图中的结构不变,仅仅是把元素的名称进行替换,就能得到一个系统的结构图:
在这里我们得到如下的对应关系:
其中公司对应系统,部门对应模块,可以理解为层级或者分组,是比较自然的,接下来我们重点看看员工和模型为什么可以对应。
"人"与"模型"的共性
首先我们思考一下,企业中员工之间是怎么协作的,我觉得无外乎下面两种情形:
- 真"手把手"教你做事;
- 我做好我的事,然后通知你,你做好你的事;
类似下图:
如果一个任务需要员工A手把手教员工B做,那是不是意味着下面几个情况:
- 员工B无法独立完成该任务;
- 员工A对该任务最终负责,或者至少是AB共同负责;
如果两个员工的协作模式模式2,即"我做好我的事,然后通知你,你做好你的事",是不是意味着:
- 员工A和员工B各自有自己的职责;
- 员工A和员工B通过"通知(事件)"来协作;
基于上述的逻辑,我们是不是可以得出下面的类比:
基于这样的类比,我们可以得出如下结论:
- 如果一个任务需要模型A直接依赖(调用)模型B,说明它们无法独自完成任务;
- 如果模型A和模型B仅通过事件协作,说明它们相互独立,职责边界清晰;
这个结论情形2是非常合理的,但如果我们遇到的是情形1,一个任务需要模型A和模型B共同的信息协作才能完成,我们一般认为有两个可选方案:
- 合并模型A和模型B,把他们看作一个整体,在模型图上的表现,就是他们之间有实线相连,他们是一个聚合整体;
- 创建模型C,来负责这个任务的解决,由模型A和模型B通过事件通知的方式把信息告诉模型C;
最终我们的模型都会是通过事件的方式协作,"人"与"模型"的共性大体如下:
- "人"与"模型"都有自己的职责,负责解决特定的业务问题;
- "人"与"模型"都拥有要履行自己职责所需要的信息;
- "人"与"模型"都通过事件驱动来协作;
拟人化建模沟通法
基于上面的推导,我们可以把一个个"模型"看作是一个个人的名字,那么在我们沟通时,就会可以用拟人化的方式来表达业务流程,表达模型的职责,表达模型身上需要携带哪些信息,表达命令与事件:
- 当"支付单"支付成功的时候,"订单"得把自己的支付状态设置成已支付;
- 当"用户"注册成功的时候,得向"用户积分账户"里发5个积分;
- "商品列表"要展示"商品信息"和"销售统计"的综合信息,还得支持各种纬度的搜索,性能还得跟得上;
通过拟人化的方式,我们可以在业务人员、产品经理、技术人员的大脑中构建比较一致的形象,这些形象对应着"职责"、"能力"和"边界",从而我们可以在一个频道上推演这些"模型"的定义和分工协作,是否真的可以满足需求,至此,我们的团队获得了一个能力,就是"有效的建模沟通",借助这个能力,我们就可以实现"需求-模型-代码"三者一致性的前半部分,即"需求-模型"的一致性:
后续
后续,我们会就"模型-代码"如何保持一致性展开剖析,敬请期待。
请关注公众号(老肖想当外语大佬)获取最新更新。