本文是上一篇《学习真DDD的最佳路径》的续篇，着重关注领域驱动设计（DDD）的核心概念。想要获取更多信息，请关注公众号（老肖想当外语大佬）。

最新文章更新；

DDD框架源码（.NET、Java双平台）；

加群畅聊，建模分析、技术实现交流；

视频和直播在B站。

打破“凭经验”的神秘面纱

每个人对事物的看法都因个人经历和认知的不同而不同。在软件工程领域，有一种著名的观点是“凭经验”来做好软件设计。然而，“凭经验”意味着无法复制，若软件设计仅依赖于经验，就如同赌博一般。

读过本系列前文《老肖的领域驱动设计之路》的朋友应该知道，我对此持有相反的观点。通过本文，我将分享我的理解，试图打破凭经验的迷信。

凭经验与主观判断

依靠经验做决策本质上是一种主观判断，尤其是那些无法由客观事实和逻辑推导的判断，或无法建立普遍共识的判断。凭经验的方法本身是主观的。如果人们仅凭过往经验做判断，那“靠左走好”和“靠右走好”就会成为普遍的观点冲突，背后的原因是“我不在乎你的看法，我只在乎我的看法”。

当然更准确的说法是“凭经验”意味着无法完全客观。

主观与客观

主观的反面是客观，客观意味着观点基于客观事实，基于符合事实的推导逻辑链，也就意味着客观决策，能够在一定的规则范围内建立共识的判断结果。由此可得出以下观点：

1. 主观判断对应非标，无法标准化

2. 客观判断对应标准，可以标准化

如果一件事情可以标准化判断，是否意味着该事情是可执行、可落地的？

需求分析和建模设计中的主观与客观

以一个需求为例：“整理房间里的物品”，解决方案可以是：“取N个收纳箱，一个个将物品放入”。在这个过程中存在主观和客观的决策。

主观的部分包括：

1. 决定使用多少个收纳箱

2. 决定哪些物品放入哪个收纳箱

客观的部分包括：

1. 收纳箱之间相互独立

2. 一个物品不会被放入两个收纳箱

将物品和收纳箱对应到建模设计中，收纳箱里装物品，而软件是领域模型负责需求点的满足，则可以这样对应：

1. 物品对应需求点

2. 收纳箱对应领域模型

基于这样的对应，我们可以推导出在需求分析和建模时，哪些部分是主观的，哪些部分是客观的。

主观的部分：

1. 有多少个领域模型

2. 哪些需求点由哪个领域模型来满足

客观的部分：

1. 领域模型之间相互独立

2. 一个需求点不会被两个领域模型来满足

回到领域驱动设计

若你跟着我的思路读到这里，并认同前面的推导逻辑及系列前文的核心观点“领域驱动是一种价值观”，那么我们发现，前面推导出的客观部分完全契合领域驱动设计价值观。而主观部分甚至未在领域驱动设计概念中提及。

因此，在软件设计中，我们认为凭经验的部分不会影响领域驱动设计价值观的践行。

我们的核心观点是，一个决策是否符合领域驱动设计，是可以客观判断的，领域驱动设计客观上可以落地执行，并不依赖个人经验。

主观的部分不重要吗

以下是建模时的主观部分：

1. 有多少个领域模型

2. 哪些需求点由哪个领域模型来满足

这部分当然也很重要，经验越丰富越容易更快速地定义出职责分配更准确的模型。但它不如“边界明确”这件事重要，因为“边界明确”解决的是结构性的问题，而主观的决策部分解决的是“局部准确性问题”。这就好比建筑中“承重墙”和“隔间墙”的关系，显然承重墙决定了整体架构，对建筑的最终效果以及未来改造成本有更深远的影响。

后续

到此，《老肖的领域驱动设计之路》系列的整体逻辑已经接近闭环。下一期将从“反DDD”的视角来剖析软件行业的乱象，以及开发者可以努力的方向。