本文书接上回《主观与客观,破除DDD凭经验魔咒》,关注公众号(老肖想当外语大佬)获取信息:
- 最新文章更新;
- DDD框架源码(.NET、Java双平台);
- 加群畅聊,建模分析、技术实现交流;
- 视频和直播在B站。
开个玩笑
“我不是针对这一个问题,我是说所有的反DDD模式都是垃圾”,作为教练,在团队中我时常用这样的玩笑来调侃不符合DDD价值观的判断逻辑和决策结果,并指出具体不符合的点在哪里,由于大家已经相互非常了解,能够很快反应过来并建立共识,从而不断修正决策逻辑和决策结果,使问题的范围和解决方案收敛在一个确定的范围内,持续地保持对系统复杂度的掌控。
===
前提条件
首先需要对齐我们讨论的场景,主要在下面的条件范围内:
- 软件系统是长期迭代的
- 软件系统是业务向的系统
在这个条件范围下,我们可以解读为:
- 我们认为迭代成本是软件成本的重要组成部分
- 我们认为自己打造的软件系统的业务复杂度高于技术复杂度
成本与复杂度
为了尽可能降低系统迭代的综合成本,本质上就是掌控系统复杂度,而系统复杂度由业务复杂度和技术复杂度共同构成。
为了实现“掌控系统复杂度”的目标,基于复杂度守恒定律,我们有以下观点:
- 复杂度不可被消除,只可被转移
- 尊重业务固有复杂度
- 避免引入额外技术复杂度
而我们在《关于领域驱动设计,大家都理解错了》一文推导过关于复杂度的结论:
- 系统复杂度与元素的数量和元素的关系有关;
- 元素的关系对系统复杂度的影响远远大于元素的数量所产生的影响;
===
核心观点
如果你已经跟随《老肖的领域驱动设计之路》系列一路读过来,那么我们接下来的推导过程就需要在之前构建的认知基础上进行,这里列出核心观点以供复习:
- 领域驱动设计是一种价值观
- DDD价值观:边界明确是最重要的事
- 软件长期主义:可维护性是最重要的事
- DDD是软件工程的第一性原理
基于上面这些观点,DDD的核心,就是掌控系统元素之间的关系,明确边界,将复杂度控制在一个个有限的范围内,完全匹配软件工程的成本控制的逻辑,那么是不是就可以得出下面的结论:
- 符合DDD价值观,意味着符合软件工程的成本利益
- 反DDD的模式,意味着不符合软件工程的成本利益
那么回到本文的标题,“所有反DDD模式都是垃圾”,更准确的描述应该是“所有反DDD模式都是不符合软件工程成本利益的”,我认为,这个逻辑是成立的。
如果你认同《DDD是软件工程的第一性原理?》一文的观点,那么同样也能得出这样的结论,违反软件工程第一性原理,当然会适得其反,走向系统快速失控的深渊。
所以,很抱歉,如果你的软件设计思维,没有围绕着“明确和维护边界”来开展,那么大概率是错误的价值判断思路,系统的复杂度大概率也很难被掌控,而具象化出来的现象,就是我们常说的“迭代不动了”。
那么,快来和我一起实践DDD吧!
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用
。你还可以使用@
来通知其他用户。