简介：畛域模型是 DDD 的外围，更是业务的深刻认知
作者简介：张刚，软件工程博士，阿里云云效资深技术专家，ALPD 方法学核心成员。
引言
畛域模型是重要的概念。然而，真正理解并能纯熟使用它的人并不多。这切实是殊为惋惜的一件事件。
软件开发中的许多问题，例如需要难于沟通，软件难以演变，都和畛域模型严密相干。更要害的是，把握这个概念并不难。通过练习，一个团队只须要一两个小时，就能够习惯畛域模型的建模思路，并且开始从中受害。
那么，什么是畛域模型？如何了解畛域模型的实质？为什么畛域模型能给软件开发带来微小帮忙？如何表白它，如何利用它？本文将顺次开展这些概念。
什么是畛域模型？
首先咱们来看什么是畛域模型。
畛域模型定义了畛域内的要害的概念以及这些概念之间的关系。
为什么要强调“畛域内”？是因为模型（或者说概念）只在它所处问题空间中才有意义。这分为两种状况：
1）一个概念只在某个特定畛域有意义。例如，“应收账款”，就只是在财务畛域，更严格的说是会计畛域才有意义。
2）一个概念必须通过畛域限定，才有具体的意义。例如，“轨道”这个概念，它可能是天文学畛域的行星静止轨道，也可能是铁路畛域的火车轨道，必须得先限定畛域，这个概念才有真正的价值。
要害信息 1：畛域模型最重要的是概念，畛域模型也被称为概念模型。
尽管有人说“畛域模型是畛域内的概念的可视化示意”，然而，“可视化”并不实质，尽管它也重要。相比较而言，“概念”才是基本。
要害信息 2：“语言的边界就是思维的边界”—— 一个好的畛域模型，必然承载了有用的常识。
对一个不相熟特定畛域的人来说，了解概念，往往是进入一个畛域最快的形式。例如，小时候的儿歌：太阳大，地球小，地球绕着太阳跑。地球大，月亮小，月亮绕着地球跑。它就能够认为是一种概念模型的表白。在这个模型中，包含了 3 个概念实体：太阳，地球和月亮。而太阳和地球的关系是地球绕着太阳静止，地球和月亮的关系是月亮绕着地球静止。用一张图画下来就是：
这张图其实是 UML 的对象图，当然即便你不相熟 UML，就是作为线框图，也能很容易了解。
同样，在各种业务畛域，都有本人的要害概念。这些概念的表白也不肯定是图。例如，方才所讲的会计畛域，咱们能够应用一张表来表白下列的几个要害概念：
通过这样一张表格，置信即便对会计畛域不甚了解对小伙伴，也能疾速把握相干的常识。如果咱们更进一步，可能了解到，应收和预付，实质上是本方的债务，而预收和应酬，实质上是本方的债权。用一张图示意就是：
在这里咱们应用了 UML 类图来示意。对于不相熟 UML 的小伙伴，可能须要解释一下三角形箭头的意思，它代表“是一种”，例如，应收账款是一种债务。
更严格的，如果一笔应收账款的帐期曾经很长，例如 5 年，那么这种账款有很大概率曾经收不回来了，所以须要计提坏账。有一些通用的坏账计提策略，例如：一年以内 5%，一到二年 20%，二到三年 50%，三年以上 100% 等。所以，面向方才的应收账款，咱们能够用上面的图来表白这样的概念：
图是一种视图，它不须要八面玲珑。例如，本图中，并没有显示所有和会计科目相干的信息，而只是集中于坏账的计提。其中，咱们在应付账款和坏账之间引入了一个新的符号，意识 UML 的小伙伴晓得咱们表白的是”应收账款中包含坏账“。图中的帐期、金额等，咱们成为“属性”，用于具体的阐明应收账款、坏账这些概念还包含哪些内容。
因为畛域模型实质上传递的是概念，是知识性的信息，所以，对于软件开发的场景来说，把这些常识显式化，能疾速对齐不同角色、不同参与方之间的概念，减速沟通，防止误会。
畛域模型是重要的业务资产
畛域概念积淀业务知识，而且十分稳固
一家在某个畛域深耕多年的企业，和一个新入行的企业，差异是什么？差距可能是多方面的，然而最大的差距应该是“认知”。——所以咱们经常会看到，新入行的企业追赶深耕多年的企业的方法，经常是去成熟的的企业高薪“挖角”。按道理说，挖来的这些人既不能把原公司的客户带来，也不可能把原公司的零碎带来，那么实质上他们给新企业带来了什么呢？他们对新公司最大的帮忙，是对特定畛域的认知。在业务畛域，认知十分值钱，而且十分稳固。咱们也会看到，一些在某个畛域建设了劣势的企业，特地是征询类企业，单靠业务畛域的征询，就能给企业带来主观的支出。如果有良好保护的畛域模型，那么畛域模型就是这些认知积淀的最佳地位所在。
更重要的是，只管业务常新，然而畛域模型却相当稳固。咱们以商品交易为例。咱们晓得买家、买家、商品、交易这些概念，都是商品交易畛域的外围概念。这些概念并不会随着业务的演进产生激烈的变动，无论是 B2C 业务，C2C 业务，C2M 业务，拼团业务还是秒杀业务。不同的业务，体现的只是对这些业务概念的不同组织形式。当然，真正的畛域模型要远远比上述概念简单的多。咱们这里只是举一个简略的例子，阐明畛域概念的稳定性。
畛域模型的跃迁和成长
当然，咱们说畛域模型稳固，并不是说它变化无穷。优良的畛域模型都肯定会继续成长，甚至有时候会产生实质的跃迁。
一旦一个模型被颠覆，咱们会认为，咱们对某个畛域的认知，肯定产生了十分实质的跃迁。例如，前述的儿歌“太阳大，地球小，地球绕着太阳跑。地球大，月亮小，月亮绕着地球跑。”并不是一开始就是这样认知的。无论中外，在几百年前，咱们都已经认为，地球是宇宙的核心，太阳、月亮都是绕着地球运行的。那么，这个模型画进去就是上面这个样子：
地心说到日心说，是咱们宇宙认知到巨大进步，认为日心说模型彻底否定了地心说模型。在软件畛域也是这样。我已经经验过几次畛域模型跃迁的场景，每次都随同这业务认知的巨大进步。
当然，在现实生活中，跃迁并不多见。更多的时候都是在原有的模型上稳固倒退，逐渐增入各种新的概念和各种细节。模型的成长过程，实质上也是业务能力积攒的过程。
稳固的畛域模型带来软件的适应性
需要是不稳定性的，而畛域模型是稳固的，这启发咱们，如果以畛域模型为核心去结构软件，那么咱们就会结构出很多稳固的积木块。新的需要，就可能通过这些稳固的积木块，通过不同的搭建形式，造成丰富多彩的利用。在这种状况下，咱们的软件对于变动的适应力最强，开发成本最低。
畛域模型存在于哪里
用类图示意畛域模型
UML 类图是表白畛域模型的十分好的工具，尽管并不存在如何表白畛域模型的规范。因为在 UML 中，“类”并不简略是软件设计中的“类”，它代表的其实是“概念”，所以，把类图用在畛域模型的表白上，是十分恰切的。而且，UML 曾经约定了概念和概念之间的关系，例如：类、属性、关联、关联的多重性、泛化、聚合、组合、依赖等等。
对于不相熟 UML 的人来说，应用 UML 也齐全没必要有什么心理累赘。UML 是一个高度灵便的构造，它具备渐近的能力。你没有必要把握所有简单的概念才开始工作，依据我的教训，只有一开始能把类（代表概念）、类的属性和它们的关系形容进去，最多再晓得多重性怎么示意，就足以应酬大多数的场景。
有些小伙伴有面向对象的教训，在这里会纠结于要不要对“办法 / 操作”进行建模。在“畛域模型”是一种“业务概念”这个上下文中，办法是齐全多余的货色，临时不须要在这个阶段进行建模。我认为在实现阶段补足它们更适合。
在交换和文档中应用畛域模型
畛域模型写在纸上并不是最要害的。作为概念模型，它反映了这个畛域的最重要的概念，也形成了表白业务概念的词汇。所以：
最好的畛域模型，应该时刻存在于团队成员的心中，存在于日常的交流活动中。
为了做到这一点，我对本人的团队和辅导过的团队，都有一个要求，这个要求也被成为交流活动中的“对立语言”：
任何在需要形容中呈现的概念，都必须呈现在畛域模型中。如果需要形容中存在概念之间的关系，畛域模型中也必须有这个关系
这个要求看似简略，理论做到会比拟艰难。特地在刚开始的时候，团队成员可能并不适应这种做法，经常就遗记了这个准则，须要常常纠正。然而一旦习惯，大家会发现，在日常交流活动中，因为所有的概念都曾经显式化，误会大大减少，共识更容易达成，导致的结果就是最初团队成员，都会十分盲目的保护“对立语言”的做法。
出于同样的起因，编写文档时，应用畛域模型作为对立语言也成了一个十分天然的后果。
在代码中应用畛域模型
因为畛域模型曾经被显式化，所以如果可能在代码中应用畛域模型，那么代码就会取得更好的易读性。因为畛域模型和代码对应的更加统一，那么在畛域模型产生演进时，代码就会变得更容易演进。在这方面，畛域驱动设计给出了一组齐备的模式，能够帮忙架构师和开发人员天然地把畛域模型转化为代码。本文中咱们并不筹备开展这些模式。在此，临时先请读者们记住上面的论断，前面会有更深刻的探讨：
代码和问题域之间的示意差距应该尽量放大，畛域模型是连贯事实世界和数字世界的最佳桥梁。应用畛域模型作为代码中的业务概念的根本表白元素，能够大幅晋升代码的易读性，也能够更好的反对业务的演进。
畛域模型来自哪里
畛域模型反映了要害的业务认知，然而认知并不会凭空建设。可能一上来就洞悉所有实质的，要么是这个人是蠢才，要么阐明这个畛域曾经是一个十分成熟的畛域，曾经无需摸索和发现。
大多数时候，认知都来自于业务场景的启发。所以，畛域模型建设的过程，往往是随同着需要剖析同步产生的。
我画了上面这张图，来阐明畛域模型和业务场景之间的关系：
也就是说，畛域模型是在业务场景的激励下逐步欠缺的。而且，反过来因为对畛域的认知更加粗浅，畛域模型还有助于新的业务场景的发现。
摸索和发现最好不要一个人单独进行。更多地时候，应该尽量进行个体建模。个体建模不仅仅利于摸索和发现，而且它也有助于达成对于要害业务概念的共识。
个体建模的最好工具并不是 UML 的电子化工具，应用白板，在凋谢空间中的探讨，往往可能收到最好的成果。
因为畛域模型表白的是概念，所以对于概念及时地合成和形象，是领域建模的基本功。当然，事实中受过严格的合成和形象训练的人并不多，特地是很多业务人员往往都不足这方面的能力。我在理论工作中，察看到具备面向对象教训的开发人员，通过肯定工夫的练习，能够很快把握这方面的技能。所以，如果有一些具备教训的开发人员参加建模，往往能够取得品质更高的模型。
常见误区
畛域模型的概念产生于 90 年代的面向对象社区。在那个时候，业务变动还不像明天这样频繁，迭代的思维也还没有齐全成熟，业务人员和技术人员也没有像明天这样密集的交换，所以，无论是从参考书上，还是实际上，畛域模型的概念都不免留下早年做法的影响。其中，有若干误区，在实践中是应该尽量避免的：
误区 1: 从开发视角进行畛域模型的建模
经常有技术人员问：“畛域模型和 ER 图有什么关系？”对这个问题最间接的答复就是：“没有关系”。诚然，我必定晓得在有了畛域模型之后，设计 ER 图会更简略，或者对于一个还不足畛域模型的遗留零碎，钻研数据库构造能够带来无效的输出，然而它们的立足点是齐全不一样的。
畛域模型肯定要从业务视角去看，因为畛域模型反映的是业务认知。一旦在畛域模型中掺杂了技术的概念，不仅仅是因为它不够纯正，更重要的是它曾经堵死了从业务视角对畛域模型进行演进和纠正的机会。因为没有软件背景的业务人员，是不可能去看一个充斥着技术概念的模型的。对立语言无奈建设，畛域模型带来的价值就曾经损失了一大部分。此外，从开发视角进行建模，往往还会漠视业务人员的参加。而实际一再表明，资深的业务人员在领域建模时，往往能提出深刻的洞察。所以，从开发视角对畛域模型进行建模相对不可取。
误区 2: 建设宏大的畛域模型
当咱们说“畛域”的时候，并没有限定一个“畛域”应该有多大。到底是“航空”作为一个畛域，还是“航空”中的“订票”是一个畛域？
当你思考到“畛域的外围是认知”，这个答案就变得十分分明了。畛域越大，越不利于建设认知和共识。咱们应该这问题域，把大的畛域划分为小的畛域，而后一一建设这些小的畛域的畛域模型。那种整整一面墙的畛域模型，往往都是不可取的。
误区 3: 重文档，轻交换和共识
畛域模型的外围在于建设独特的共识，所以，如果只是把畛域模型作为一种“制品”，作为某个阶段的“输入”，这是十分不适合的。畛域模型须要作为交换工具。“对立语言”是防止该误区的重要办法。
误区 4: 不把畛域模型显式化
很多人认为本人是有“认知”的，甚至是有“畛域模型”的，然而，如果你问他们模型在哪里，这些要么就是在某个我的项目已经有过一些探讨，然而当初曾经不知所踪，要么就是尽管文档还在，然而团队的概念表白仍旧凌乱。没有显式化，没有把畛域模型写下来，没有造成团队口口相传的常识，那么这种模型，并不真正存在。除了“对立语言”，咱们还有一个十分简便的测验办法，就是看这个团队如何给新人介绍本人的零碎。因为畛域模型反映了根本的业务概念，是一个十分好的新人造就工具，凡是真正有“畛域模型”的组织，是不可能不把畛域模型拿进去做介绍的。
总结
本文咱们次要介绍了畛域模型的基本概念及重要度，畛域模型对于“对立语言”的价值以及畛域模型利用的常见误区。
总结一下要点：
• 畛域模型的实质是概念和认知，它定义了畛域内的要害概念以及这些概念之间的关系
• 绝对于业务的多变，畛域模型绝对稳固，优质的畛域模型能够低成本的反对业务，畛域模型也是对立语言的根底，能无效晋升沟通效率
• 畛域模型来自于业务滋润，畛域模型成长的过程，也是业务认知建设的过程，合作建模是更无效的建模办法。
原文链接
本文为阿里云原创内容，未经容许不得转载。