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