最新文章更新；
DDD框架源码（.NET、Java双平台）；
加群畅聊，建模分析、技术实现交流；
视频和直播在B站。
神秘的“凭经验”
一千个人眼中有一千个哈姆雷特，每个人的经历不同，认知不同，那么看待哈姆雷特的角度和感受也不同。在软件工程领域，也有著名的关于如何做好软件设计的观点：“凭经验”。然而，“凭经验”就意味着不可复制，如果软件设计只能凭经验，那还不如说是撞大运。
读过本系列前文《老肖的领域驱动设计之路》的朋友，应该知道，我对此是持相反的观点的，今天通过几分钟的篇幅，呈现我的理解，尝试破除凭经验的魔咒。
凭经验与主观判断
首先，我认为依靠经验来决策，本质上是一种主观判断，尤其是那些无法由客观事实和逻辑推导的判断和无法建立普遍共识的判断。至少凭经验这个方法本身，是主观的。试想一下，如果人们都仅仅依靠自己的过往经验来做判断，那么“靠左走好”和“靠右走好”就会成为普遍的观点冲突，而这个冲突的背后就是，“我不要你觉得，我要我觉得”。
当然更准确的说法是“凭经验”意味着不能绝对客观。
主观与客观
主观的反面是客观，客观意味着观点基于客观事实，基于符合事实的推导逻辑链，也就意味着客观决策，能够在一定的规则范围内建立共识的判断结果，那么我们可以得到如下观点：
主观判断对应非标，无法标准化
客观判断对应标准，可以标准化
如果对于一件事情可以标准化判断，是不是意味着这件事是可执行、可落地的？
需求分析和建模设计中的主观与客观
先举个例子，假设我们有个需求：“整理房间里的物品”，那么我们的解决方案可以是：“取N个收纳箱，把物品一个个放进去”，那么这里就有一些主观和客观的决策在里面。
主观的部分有：
决定用多少个收纳箱
哪些物品放哪个收纳箱
客观的部分有：
收纳箱之间相互独立
一个物品不会被放在两个收纳箱里
如果我们将物品和收纳箱对应到建模设计中，收纳箱里装物品，而软件是领域模型负责需求点的满足，则可以这样对应：
物品对应需求点
收纳箱对应领域模型
基于这样的对应，我们可以推导出我们在需求分析和建模时候，哪些部分是主观的，哪些部分又是客观的。
主观的部分：
有多少个领域模型
哪些需求点由哪个领域模型来满足
客观的部分：
领域模型之间相互独立
一个需求点不被两个领域模型来满足
回到领域驱动设计
如果你是跟着我的思路读到这里，并且认同前面的推导逻辑以及系列前文的核心观点“领域驱动是一种价值观”，这种价值观是“边界明确是最重要的事”，最精彩的部分来了，你会发现，我们前面推导出来客观的部分，是完全契合领域驱动设计价值观的。而主观的部分，甚至都不曾在领域驱动设计概念里提及。
所以，回到文章的开头关于凭经验的说法，我们认为软件设计中，凭经验的部分不会影响领域驱动设计价值观的践行。
那么我们的核心观点是，一个决策是否符合领域驱动设计，是可以客观判断的，领域驱动设计客观上可以落地执行，并不依赖人的经验。
主观的部分不重要吗
我们再把建模时候主观的部分列出来：
有多少个领域模型
哪些需求点由哪个领域模型来满足
这部分当然也很重要，经验越丰富越容易更快速地定义出职责分配更准确的模型，但它不如“边界明确”这件事重要，因为“边界明确”解决的是结构性的问题，而主观的决策部分解决的是“局部准确性问题”，这就好比建筑里的“承重墙”和“隔间墙”之间的关系，显然承重墙决定了整体的架构，对建筑最终效果以及未来改造成本有更深远的影响。
后续
到此，《老肖的领域驱动设计之路》系列的整体逻辑已经接近闭环，下一期将从“反DDD”的视角来剖析软件行业的乱象，以及开发者可以努力的方向。