本文书接上回《
主观与客观,破除DDD凭经验魔咒
》,关注公众号(老肖想当外语大佬)获取信息:

  1. 最新文章更新;

  2. DDD框架源码(.NET、Java双平台);

  3. 加群畅聊,建模分析、技术实现交流;

  4. 视频和直播在B站。

开个玩笑

“我不是针对这一个问题,我是说所有的反DDD模式都是垃圾”,作为教练,在团队中我时常用这样的玩笑来调侃不符合DDD价值观的判断逻辑和决策结果,并指出具体不符合的点在哪里,由于大家已经相互非常了解,能够很快反应过来并建立共识,从而不断修正决策逻辑和决策结果,使问题的范围和解决方案收敛在一个确定的范围内,持续地保持对系统复杂度的掌控。

===

前提条件

首先需要对齐我们讨论的场景,主要在下面的条件范围内:

  1. 软件系统是长期迭代的

  2. 软件系统是业务向的系统

在这个条件范围下,我们可以解读为:

  1. 我们认为迭代成本是软件成本的重要组成部分

  2. 我们认为自己打造的软件系统的业务复杂度高于技术复杂度

成本与复杂度

为了尽可能降低系统迭代的综合成本,本质上就是掌控系统复杂度,而系统复杂度由业务复杂度和技术复杂度共同构成。

为了实现“掌控系统复杂度”的目标,基于复杂度守恒定律,我们有以下观点:

  1. 复杂度不可被消除,只可被转移

  2. 尊重业务固有复杂度

  3. 避免引入额外技术复杂度

而我们在《
关于领域驱动设计,大家都理解错了
》一文推导过关于复杂度的结论:

  1. 系统复杂度与元素的数量和元素的关系有关;

  2. 元素的关系对系统复杂度的影响远远大于元素的数量所产生的影响;

===

核心观点

如果你已经跟随《
老肖的领域驱动设计之路
》系列一路读过来,那么我们接下来的推导过程就需要在之前构建的认知基础上进行,这里列出核心观点以供复习:

  1. 领域驱动设计是一种价值观

  2. DDD价值观:边界明确是最重要的事

  3. 软件长期主义:可维护性是最重要的事

  4. DDD是软件工程的第一性原理

基于上面这些观点,DDD的核心,就是掌控系统元素之间的关系,明确边界,将复杂度控制在一个个有限的范围内,完全匹配软件工程的成本控制的逻辑,那么是不是就可以得出下面的结论:

  1. 符合DDD价值观,意味着符合软件工程的成本利益

  2. 反DDD的模式,意味着不符合软件工程的成本利益

那么回到本文的标题,“所有反DDD模式都是垃圾”,更准确的描述应该是“所有反DDD模式都是不符合软件工程成本利益的”,我认为,这个逻辑是成立的。

如果你认同《
DDD是软件工程的第一性原理?
》一文的观点,那么同样也能得出这样的结论,违反软件工程第一性原理,当然会适得其反,走向系统快速失控的深渊。

所以,很抱歉,如果你的软件设计思维,没有围绕着“明确和维护边界”来开展,那么大概率是错误的价值判断思路,系统的复杂度大概率也很难被掌控,而具象化出来的现象,就是我们常说的“迭代不动了”。

那么,快来和我一起实践DDD吧!

标签: none

添加新评论