先有鸡还是先有蛋？这是领域驱动设计落地最大的困局

本文书接上回 《关于领域驱动设计，大家都理解错了》,关注公众号（老肖想当外语大佬）获取信息：

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

https://mp.weixin.qq.com/s/HHJ5vt2\_iT0-CFcw0HcPnA

先有鸡还是先有蛋的困局

前文我们提出了“领域驱动设计是一种价值观”这个观点，那么落地领域驱动设计就是践行价值观的过程，实践过程中势必需要一些方法来指导，那么问题来了，一个团队要落地领域驱动设计，是先有认知还是先有方法呢？

如果团队没有“识别范围和边界是最重要的事”这样的认知，那么大概率也不会关注它，“方法”就无从谈起，如果没有“方法”，你大概率也体会不到“识别范围和边界是最重要的事”这样价值观带来的好处，那么就很难构建起这样的价值观，因此就陷入了一个“先有鸡还是先有蛋”的困局，这也是现实中大多数研发团队面临的困局，即使团队中有人意识到这个问题，普遍地也是无能为力。

核心问题是什么？

你可以审视一下自己的团队，在需求分析的时候，是否真的建立了需求边界的共识？产品经理在定义产品功能的时候，又是否真的把功能的边界、目的、以及对应的需求给团队讲明白了？再看看你的代码，是否每个类的职责和目的都是清晰的？

如果以上问题的答案都是肯定的，那么，你也不会觉得需求难分析、功能难设计、代码难修改了。我相信，大部分团队的答案，都是“否”，而且这些问题，最后都会以程序员背负着“迭代交付效率低下”这口大锅，然后拼命用加班来补偿而告终，然而这个锅的罪魁祸首却在立项的那一刻已经埋下了，很多的隐性代价在项目初期被忽视，无边界的问题、模糊的需求、凑合的建模、背离现实的扩展性设计、匮乏的测试用例等等一系列的不确定性，在团队的工作流程里一步步被放大，而这个锅该不该由流程下游才介入的程序员们来背，是值得商榷的。但组织的管理者并没有这个认知，没有这个判断力，他们只会看到工期紧任务重，程序员们出活慢。

那么问题来了，一个事情做不好，是决策者的锅大，还是执行者的锅大呢？

决策者是最大的绊脚石

在我看来，最大的锅应该是团队决策者的，首先，这一系列的问题本质就是没有意识到“把问题的边界和范围搞清楚”是最重要的事，下达的很多决策都是脱离实际的。

“团队成员无法推动团队价值观的变化”，这是因为价值观的现实体现，就是决策结果，而团队的决策其实是由管理者最终拍板的，因此管理者的价值观就是团队价值观。

设想一下，假如老板不期望员工加班，员工大概率不用加班，反之结果，就是普遍意义上的各种996、福报、奋斗逼。老板的价值观，就是企业的价值观，因为各种决策是老板做的，决策本身就是价值观的体现。放到研发团队里，团队主管就是那个下决策的人，诚然很多经验丰富的开发者、架构师对于软件设计有丰富的经验和独到的见解，仍然架不住领导一句“明天这个功能就得上线”、“客户要得急”、“先上线再说”。

所以我的观点是：

• 决策者在做决策时，核心价值判断出现了偏差；
• 决策者对自己的决策后果，缺乏充分的判断力；

所以，决策者是领域驱动设计落地最大的绊脚石。

落地领域驱动设计的必要条件

要成功在团队中实践“领域驱动设计价值观”，就必须把识别和明确边界作为首要决策依据，那么需要做到下面几点：

• 所有的需求都有明确的边界定义
• 所有的功能设计都有明确的边界定义
• 所有的业务模型都有明确的边界定义
• 所有的代码都有明确的边界定义

而要做到这些，就必须由决策者直接或者授权团队在这些问题上做充分的沟通和讨论，所做的决定必须是明确的，哪怕是有限信息下的决策，也得明确有多少是确定的，有多少是团队建立了一个猜的共识，这些决策都明确的情况下，团队的最终执行，就一定是符合领域驱动设计价值观的。

此外，如果有下面两条，那么团队落地领域驱动设计的顺畅程度会大大提高：

• 一套匹配的DDD战术框架
• 一组执行力强的开发团队

这两条，我们在后续更具体实战操作中更详细地展开和说明。

关键角色的能力模型

既然，决策者是最关键的角色，那么这个角色需要具备哪些能力呢？

首先，决策者的核心职责如下：

• 理解业务与需求
• 业务建模
• 确保研发按照模型交付

具象化出来就是“业务专家的话你听得懂”、“产品经理懂的你得懂”、“研发的方案你看得懂”，这个角色需要能够与各个角色充分地交流和协作，并且对技术有充分的了解，那么就必须有足够的“判断力”、“表达力”、“协作力”以及“技术功底”。

有这些能力做支撑，才能够在沟通互动中捕捉关键信息，识别问题的边界，给出匹配的方案，才能判断一个决策的范围和边界是否足够明确，是否在团队中建立了共识，是否明确了不可共识的部分。

改变的起点是相信“相信的力量”

在回到文章开头，要打破“先有鸡还是先有蛋”这个困局，需要团队管理者身上突破，管理者得先意识到，问题的边界、解决方案的边界的重要性，先理解系统迭代慢这件事背后的核心因素就是在决策时把很多需要明确的问题推迟了，这个推迟，导致了团队付出大量额外的代价来补偿，以应对决策时的不确定性，伪需求、没人用的功能、无意义的扩展性等等问题都是在一个个决策中产生的，而大家看到最终的结果，就是研发团队的效率低下，一个小小的功能都迭代不上去，这个锅扣在程序员身上是不符合事实的。

因此，要做出改变，先要相信“相信的力量”，你看到了这篇文章，尝试理解了“范围和边界是最重要的事”这样的价值观，那么接下来就是不断地在每次决策和讨论中实践它，不断自我审视自己的决策，是否把范围和边界弄清楚了，尽可能地向这个方向靠拢，我也相信，因为你的相信，一定能够收获到“相信”的价值。

不是决策者，我该怎么办

如果你不是决策者，而你又认同“领域驱动设计是一种价值观”，那么你有三个选择：

1. 将这个观点与你的领导沟通，尝试推动领导与你建立共识，获取信任并帮助团队做决策；
2. 努力自己成为决策者；
3. 以上都行不通，也许你该换个更加开放组织了；

后续

到此，领域驱动设计的概念和核心落地的核心角色已经描述完毕，期待与大家对这些观点来讨论沟通。

接下来，将展开探讨作为领域驱动设计的核心角色，具体应该如何操作，帮助团队将这个价值观内化到日常工作行为中来。