领域驱动设计 101 - 领域、知识、组织结构及模型

领域驱动设计正变得越来越流行。

一方面，领域驱动设计重新回归面向对象的本质并且提出一整套系统的实践模型。不可否认，编程框架为构建大型应用提供了极大的便利，其本身也充满面向对象的设计语言，但是，这种框架提供的便捷性使得在编写业务代码时，只需要编写符合框架规则的事物脚本就能够解决大部分问题。正是这种便捷性逐渐地阉割了大部分面向用户的应用软件开发设计中的面向对象方法。

另一方面，随着计算机技术和互联网技术的发展，采用软件解决现实世界的问题变得越来越普遍，当软件开发开始被社会的各行各业所采用的时候，实践的升级和方法论的提炼是必然的。

另外，传统行业开始普遍转向采用计算机和互联网技术来转向业务发展新的高速赛道，即所谓的数字化转型。在这一过程中，按照业务领域进行分割和治理应用显现除了强大的能量，似乎适应各种可大可小的场景。

因此，了解领域驱动设计这一软件开发设计的方法论恰在其时，很有必要。

领域驱动设计 - 字面意义上的概念理解

领域驱动设计提出了一整套理论，要完全理解并掌握这些概念所要表达的含义，再理清楚他们之间的联系和区别本身就需要不小的成本。如果要将这套方法落地于实际的项目当中需要花费更大的代价，其中包括了团队的学习成本以及反复实践的试错成本。

那么，面对这这一略显高深的概念难道只能一头扎进去钻研吗。至少，我们可以先从字面上先进行理解：

领域（Domain）：领域驱动设计所研究的对象是软件开发，软件开发的核心目标是通过设计开发软件来解决用户在现实世界中的问题。所以，这里的领域便是 - 面向用户的应用软件中的问题区域。或者用我们更加熟悉的话，进行软件设计开发时所面向的业务范围。

驱动（Driven）：发动机带动轮子转动，领导命令员工干活。A 为 B 的运转提供直接或者间接的动力，所谓驱动。

设计（Design）：这里的设计毫无疑问是软件设计，但是需要明确的是并不仅仅是通常理解的在动手编写程序之前进行算法、数据结构、框架挑选和制定。这里的设计至少包含了：分析 - 形成业务模型，设计 - 算法、数据结构、框架挑选和制定，软件开发 - 通常意义上理解的编码（但必须知道编码的同时无时无刻不伴随着设计，那些认为编码仅仅是一遍遍重复相同的动作的情况，要么是这个软件价值不高，要么是还不会开发）。

综合起来，可以这样认识领域驱动设计：采用分析业务领域的方法使软件设计（广义的设计）有效运转。

知识消化

让我们考虑一般的软件开发过程。

首先，业务人员将现实世界中的需要解决的问题进行总结归纳，提出所谓的业务需求。然后，开发团队在拿到这份需求后再进行加工，加工的过程是基于需求描述进行分析，将其中的问题、概念、原则、操作、关系等等提取出来，形成一个贴近软件开发语言体系的业务模型。接着，团队将采用软件开发的专业方法将其转换为一份软件设计，这种设计可以是文档形式，也可以是 UML 图等等。最后，团队根据形成的设计进行编码开发、测试、上线。

可以看到，在这个过程的每个环节中，都进行了知识的转化，也就是加工。每个环节都以上一个环节形成的结果作为输入信息，结合已经具备的专业知识工具进行处理，形成这一环节的输出。而输出的结果不过是对问题领域的另一种描述形式。

再分析上述流程：

1. 在需求分析的过程中，对需求中包含的知识进行提取，找到其中有用、关键的信息，构建出一个初始的模型。

2. 在设计的过程中，对知识进行重新组织，以有效、直观、易懂的形式组织，例如文档、图等。

3. 最终，进行软件开发所依据的设计文档、图例等可以看做是最初业务提出的需求所涉及业务领域中知识的某种简化视图。

综合上述分析，软件设计可以看做是一个知识消化、加工的过程，在这个过程中知识得到完整、有效的转化是关键。

组织结构

在上面一小节讨论时所采用的软件设计过程基本符合瀑布式开发模式，每个环节都向下一个环节产出必要的成果作为输入。整个过程是开放的过程，如果将软件开发视作一个系统，那么这个系统将是一个开环系统，最开始的输入逐个环节传递，经过层层加工形成最终的输出-应用软件。很明显，开环的系统至少有两个问题：

1. 输入的信息（知识）经过系统的各个环节加工后必然有损耗，最终能够被正确保留或者体现出来的有多少，很难保证。

2. 开环的信息流向缺少回路，系统不能根据自身的运行状态自行调整，因而很难形成稳定可靠的输出。

如果以这个过程中的人员作为关键节点来表示软件开发过程中的知识流动，那么瀑布式开发过程的将如下图所示。虽然在图中，画出了两条反向的信息流动路径，但需要知道在瀑布式开发过程中这种信息流动是很少出现的，这一方面是受开发模式限制，同时也经常受到了组织形式的限制（因为三种角色的人员通常并不在同一个团队或者部门）。我们可以将这种软件开发模式称为“脆弱闭环”模式。

如今，软件开发越来越普遍地开始采用迭代式开发，在所谓“敏捷”思想的指导下进行。这种开发过程的图示如下：

这时，Product Owner 承担了一部分业务分析师的职责，并且与开发工程师将在同一个团队/小组中工作，信息流动将不再是单向的，开发工程师有了形式上的权利和便利向 PO 提出问题和自己的想法。从而，在这一部分中形成了一个闭环过程，这给整个“系统”进行一定程度的自我调整提供了可能。

这个时候，系统的有效运转严重依赖于 Product Owner 与业务专家间的“脆弱”反馈，但通常情况下这种反馈往往成本高、效率低，最终这种模式下面也难以开发出真正符合用户实际需要的应用。此外，由于采用了 PO 和开发工程师一个小组的组织形式，这个时候小组内通常会自发地出现对产品发展的觉醒，但往往产品的发展决定权并不在开发小组中，这种心有余而无处使劲的状态往往会慢慢消耗整个小组的创意和动力，很可能最终开发和 PO 之间的沟通热情也被消耗殆尽，在实质上退化到瀑布式开发模式上去。

让我们再来看看所谓“融合型”或者“柔性”组织结构下面的情况：

现在，业务专家、Product Owner、开发工程师济济一堂，他们在同一个团队/小组内进行工作，信息不仅可以在开发、Product Owner， Product Owner、业务专家之间反向流动，甚至可以在业务专家和开发工程师之间流动。信息的充分流动为“系统”进行自我调整提供了足够的可能，损耗和不可控的因素被降到最低，从而敏捷所倡导的通过短时间内迭代产出一个个稳定的可用软件版本才真正意义上称为了可能。

这种组织结构还会带来如下额外的收益：

1. 与业务专家同处一个小组内使得开发人员不得不学习关于业务的关键知识，他们再也不是拿着断头去尾的用户故事慢慢自己咂摸、味同嚼蜡，对业务知识的充分理解使得他们更加充分地认识到了业务场景的本质，从而更有可能开发出有血有肉的软件。

2. 业务专家为了和开发人员处于一个频道，不得不将业务领域内的信息进行充分分析、提取，他们能够很容易就听到下游传递来的声音，这为及时补充、调整业务需求提供了基础，从而也再也不必在看到成品是慨叹“这是个啥！”。

3. 经过充分磨合之后，小组的运行逐渐顺畅，新的创意和想法不断迸发，这些创意和想法也能够及时被得到响应，不再石沉大海（即使被否决，也是被“自己”否决）。这不仅为反复试错提供了更多的机会，同时也必然会打磨出更加合理的软件产品。

领域驱动设计并未对组织结构进行严格的限制，但是必须承认只有采用融合型的组织形式才能充分发挥领域驱动设计所蕴含的最大力量。同时，不论采用哪种软件开发设计模式，把所有重要干系人组织到一起带来的信息充分流动为形成高效组织提供了必要的基础。

模型

让我们从讨论那些“飘”着的东西中暂时回来，回到实际的问题当中。

在前面的讨论中，我们反复提到了模型这一概念。领域驱动设计强调，在完成领域分析之后，在进行软件开发之前，我们需要建立一套业务模型，并反复打磨这套模型，最终完成软件开发时，这套模型应该是无限趋近于我们实际面向的业务领域的。那么，什么是业务模型？

前面已经讨论了知识，软件设计过程是一个知识加工、消化的过程。既然模型是软件设计过程中的产物，那么模型同样是某种知识。如果对比实际业务领域所包含的知识，那么模型可以看做是经过选择性简化和有意识结构化的浓缩的知识。

1. 模型是经过简化后的知识，保持业务领域实际的复杂度进行分析成本过高，模型中只保留那些关键的信息，无关紧要的暂时被忽略。

2. 模型是组织起来的，结构化的信息，只有用分析出明确的结构，人脑才能认识到信息之间的关系。

3. 模型不可能包含所有的业务领域信息，只有那些重要的信息会被保留到模型中。

以上，我们首先从字面意义上讨论了领域驱动设计所要表达的含义；然后，从领域驱动设计强调的知识加工的角度对软件开发过程进行分析；接着，基于知识加工视角采用系统化的方法分析了不同组织结构下进行软件开发的效果；最后，对领域驱动强调的模型进行了简要分析。只有透彻理解领域、知识、模型、组织结构这几个方面，才能明白领域驱动设计的出发点和前提。