为何你应该关心领域模型?

简介:领域模型是DDD的核心,更是业务的深刻认知

做者简介:张刚,软件工程博士,阿里云云效资深技术专家,ALPD方法学核心成员。数据库

读者福利:前往:架构

https://developer.aliyun.com/topic/course/alpd工具

免费领取阿里爆款架构师课程《DDD高手进阶12讲》(原价98元)。学习

引言

领域模型是重要的概念。可是,真正了解并能熟练运用它的人并很少。这实在是殊为惋惜的一件事情。阿里云

软件开发中的许多问题,例如需求难于沟通,软件难以演化,都和领域模型紧密相关。更关键的是,掌握这个概念并不难。经过练习,一个团队只须要一两个小时,就能够习惯领域模型的建模思路,而且开始从中受益。spa

那么,什么是领域模型?如何理解领域模型的本质?为何领域模型能给软件开发带来巨大帮助?如何表达它,如何应用它?本文将依次展开这些概念。设计

什么是领域模型?

首先咱们来看什么是领域模型。对象

领域模​型定义了领域内的关键的概念以及这些概念之间的关系。图片

为何要强调“领域内”?是由于模型(或者说概念)只在它所处问题空间中才有意义。这分为两种状况:开发

1)一个概念只在某个特定领域有意义。例如,“应收帐款”,就只是在财务领域,更严格的说是会计领域才有意义。

2)一个概念必须经过领域限定,才有具体的意义。例如,“轨道”这个概念,它多是天文学领域的行星运动轨道,也多是铁路领域的火车轨道,必须得先限定领域,这个概念才有真正的价值。

关键信息1:领域模型最重要的是概念,领域模型也被称为概念模型。

虽然有人说“领域模型是领域内的概念的可视化表示”,可是, “可视化”并不本质,虽然它也重要。相比较而言,“概念”才是根本。

关键信息2:“语言的边界就是思想的边界”—— 一个好的领域模型,必然承载了有用的知识。

对一个不熟悉特定领域的人来讲,理解概念,每每是进入一个领域最快的方式。例如,小时候的儿歌:太阳大,地球小,地球绕着太阳跑。地球大,月亮小,月亮绕着地球跑。它就能够认为是一种概念模型的表达。在这个模型中,包括了3个概念实体:太阳,地球和月亮。而太阳和地球的关系是地球绕着太阳运动,地球和月亮的关系是月亮绕着地球运动。用一张图画下来就是:

图片 1.png

这张图实际上是UML的对象图,固然即便你不熟悉UML,就是做为线框图,也能很容易理解。

一样,在各类业务领域,都有本身的关键概念。这些概念的表达也不必定是图。例如,刚才所讲的会计领域,咱们可使用一张表来表达下列的几个关键概念:

<span>会计主体(本方)->对方</span>
<span>应收帐款</span> <span>货物已经发给对方,可是还没有收到货款</span>
<span>应付帐款</span> <span>已经收到对方货物,可是还没有支付货款</span>
<span>预收帐款</span> <span>已经收到对方货款,可是还没有发货</span>
<span>预付帐款</span> <span>已经支付对方货款,可是还没有收到货物</span>
经过这样一张表格,相信即便对会计领域不甚了解对小伙伴,也能快速掌握相关的知识。若是咱们更进一步,可以理解到,应收和预付,本质上是本方的债权,而预收和应付,本质上是本方的债务。用一张图表示就是: 图片 2.png 在这里咱们使用了UML类图来表示。对于不熟悉UML的小伙伴,可能须要解释一下三角形箭头的意思,它表明“是一种”,例如,应收帐款是一种债权。 更严格的,若是一笔应收帐款的账期已经很长,例如5年,那么这种帐款有很大几率已经收不回来了,因此须要计提坏帐。有一些通用的坏帐计提策略,例如:一年之内5%,一到二年20%,二到三年50%,三年以上100%等。因此,面向刚才的应收帐款,咱们能够用下面的图来表达这样的概念: 图片 3.png 图是一种视图,它不须要面面俱到。例如,本图中,并无显示一切和会计科目相关的信息,而只是集中于坏帐的计提。其中,咱们在应付帐款和坏帐之间引入了一个新的符号,认识UML的小伙伴知道咱们表达的是”应​收帐款中包括坏帐“。图中的账期、金额等,咱们成为“属性”,用于详细的说明应收帐款、坏帐这些概念还包括哪些内容。 ​ 因为领域模型本质上传递的是概念,是知识性的信息,因此,对于软件开发的场景来讲,把这些知识显式化,能快速对齐不一样角色、不一样参与方之间的概念,加速沟通,避免误解。 ​ # 领域模型是重要的业务资产 ## 领域概念沉淀业务知识,并且很是稳定。 一家在某个领域深耕多年的企业,和一个新入行的企业,差异是什么?差距多是多方面的,可是最大的差距应该是“认知”。——因此咱们经常会看到,新入行的企业追赶深耕多年的企业的办法,经常是去成熟的的企业高薪“挖角”。按道理说,挖来的这些人既不能把原公司的客户带来,也不可能把原公司的系统带来,那么本质上他们给新企业带来了什么呢?他们对新公司最大的帮助,是对特定领域的认知。在业务领域,认知很是值钱,并且很是稳定。咱们也会看到,一些在某个领域创建了优点的企业,特别是咨询类企业,单靠业务领域的咨询,就能给企业带来客观的收入。若是有良好维护的领域模型,那么领域模型就是这些认知沉淀的最佳位置所在。 更重要的是,尽管业务常新,可是领域模型却至关稳定。咱们以商品交易为例。咱们知道买家、买家、商品、交易这些概念,都是商品交易领域的核心概念。这些概念并不会随着业务的演进发生剧烈的变化,不管是B2C业务,C2C业务,C2M业务,拼团业务仍是秒杀业务。不一样的业务,体现的只是对这些业务概念的不一样组织方式。固然,真正的领域模型要远远比上述概念复杂的多。咱们这里只是举一个简单的例子,说明领域概念的稳定性。 ## 领域模型的跃迁和生长 固然,咱们说领域模型稳定,并非说它一成不变。优秀的领域模型都必定会持续生长,甚至有时候会发生本质的跃迁。 一旦一个模型被推翻,咱们会认为,咱们对某个领域的认知,必定发生了很是本质的跃迁。例如,前述的儿歌“太阳大,地球小,地球绕着太阳跑。地球大,月亮小,月亮绕着地球跑。”并非一开始就是这样认知的。不管中外,在几百年前,咱们都曾经认为,地球是宇宙的中心,太阳、月亮都是绕着地球运行的。那么,这个模型画出来就是下面这个样子: 图片 4.png 地心说对象图 地心说到日心说,是咱们宇宙认知到巨大进步,觉得日心说模型完全否认了地心说模型。在软件领域也是这样。我曾经经历过几回领域模型跃迁的场景,每次都伴随这业务认知的巨大进步。 固然,在现实生活中,跃迁并很少见。更多的时候都是在原有的模型上稳定发展,逐步增入各类新的概念和各类细节。模型的生长过程,本质上也是业务能力积累的过程。 ## 稳定的领域模型带来软件的适应性 需求是不稳定性的,而领域模型是稳定的,这启发咱们,若是以领域模型为中心去构造软件,那么咱们就会构造出不少稳定的积木块。新的需求,就可能经过这些稳定的积木块,经过不一样的搭建方式,造成丰富多彩的应用。在这种状况下,咱们的软件对于变化的适应力最强,开发成本最低。 # 领域模型存在于哪里 ## 用类图表示领域模型 UML类图是表达领域模型的很是好的工具,虽然并不存在如何表达领域模型的标准。由于在UML中,“类”并不简单是软件设计中的“类”,它表明的实际上是“概念”,因此,把类图用在领域模型的表达上,是很是恰切的。并且,UML已经约定了概念和概念之间的关系,例如:类、属性、关联、关联的多重性、泛化、聚合、组合、依赖等等。 对于不熟悉UML的人来讲,使用UML也彻底不必有什么心理负担。UML是一个高度灵活的结构,它具备渐近的能力。你没有必要掌握全部复杂的概念才开始工做,根据个人经验,只要一开始能把类(表明概念)、类的属性和它们的关系描述出来,最多再知道多重性怎么表示,就足以应付大多数的场景。 有些小伙伴有面向对象的经验,在这里会纠结于要不要对“方法/操做”进行建模。在“领域模型”是一种“业务概念”这个上下文中,方法是彻底多余的东西,暂时不须要在这个阶段进行建模。我认为在实现阶段补足它们更合适。 ## 在交流和文档中使用领域模型 领域模型写在纸上并非最关键的。做为概念模型,它反映了这个领域的最重要的概念,也构成了表达业务概念的词汇。因此: 最好的领域模型,应该时刻存在于团队成员的心中,存在于平常的交流活动中。 ​ 为了作到这一点,我对本身的团队和辅导过的团队,都有一个要求,这个要求也被成为交流活动中的“统一语言”: 任何在需求描述中出现的概念,都必须出如今领域模型中。若是需求描述中存在概念之间的关系,领域模型中也必须有这个关系 这个要求看似简单,实际作到会比较困难。特别在刚开始的时候,团队成员可能并不适应这种作法,经常就忘记了这个准则,须要常常纠正。可是一旦习惯,你们会发现,在平常交流活动中,由于全部的概念都已经显式化,误解大大减小,共识更容易达成,致使的后果就是最后团队成员,都会很是自觉的维护“统一语言”的作法。 出于一样的缘由,编写文档时,使用领域模型做为统一语言也成了一个很是天然的结果。 ## 在代码中使用领域模型 因为领域模型已经被显式化,因此若是可以在代码中使用领域模型,那么代码就会得到更好的易读性。因为领域模型和代码对应的更加一致,那么在领域模型发生演进时,代码就会变得更容易演进。在这方面,领域驱动设计给出了一组完备的模式,能够帮助架构师和开发人员天然地把领域模型转化为代码。本文中咱们并不许备展开这些模式。在此,暂时先请读者们记住下面的结论,后面会有更深刻的讨论: 代码和问题域之间的表示差距应该尽可能缩小,领域模型是链接现实世界和数字世界的最佳桥梁。使用领域模型做为代码中的业务概念的基本表达元素,能够大幅提高代码的易读性,也能够更好的支持业务的演进。 # 领域模型来自哪里 领域模型反映了关键的业务认知,可是认知并不会凭空创建。可以一上来就洞悉一切本质的,要么是这我的是天才,要么说明这个领域已是一个很是成熟的领域,已经无需探索和发现。 大多数时候,认知都来自于业务场景的启发。因此,领域模型创建的过程,每每是伴随着需求分析同步产生的。 我画了下面这张图,来讲明领域模型和业务场景之间的关系: 图片 5.png 也就是说,领域模型是在业务场景的激励下逐渐完善的。并且,反过来由于对领域的认知更加深入,领域模型还有助于新的业务场景的发现。 探索和发现最好不要一我的独自进行。更多地时候,应该尽可能进行集体建模。集体建模不只仅利于探索和发现,并且它也有助于达成对于关键业务概念的共识。 集体建模的最好工具并非UML的电子化工具,使用白板,在开放空间中的讨论,每每可以收到最好的效果。 因为领域模型表达的是概念,因此对于概念及时地分解和抽象,是领域建模的基本功。固然,现实中受过严格的分解和抽象训练的人并很少,特别是不少业务人员每每都缺少这方面的能力。我在实际工做中,观察到具备面向对象经验的开发人员,通过必定时间的练习,能够很快掌握这方面的技能。因此,若是有一些具备经验的开发人员参与建模,每每能够得到质量更高的模型。 # 常见误区 领域模型的概念产生于90年代的面向对象社区。在那个时候,业务变化还不像今天这样频繁,迭代的思想也尚未彻底成熟,业务人员和技术人员也没有像今天这样密集的交流,因此,不管是从参考书上,仍是实践上,领域模型的概念都不免留下早年作法的影响。其中,有若干误区,在实践中是应该尽可能避免的: ## 误区1:  从开发视角进行领域模型的建模 经常有技术人员问:“领域模型和ER图有什么关系?” 对这个问题最直接的回答就是:“没有关系”。当然,我确定知道在有了领域模型以后,设计ER图会更简单,或者对于一个还缺少领域模型的遗留系统,研究数据库结构能够带来有效的输入,可是它们的立足点是彻底不同的。 领域模型必定要从业务视角去看,由于领域模型反映的是业务认知。一旦在领域模型中掺杂了技术的概念,不只仅是由于它不够纯粹,更重要的是它已经堵死了从业务视角对领域模型进行演进和纠正的机会。由于没有软件背景的业务人员,是不可能去看一个充斥着技术概念的模型的。统一语言没法创建,领域模型带来的价值就已经损失了一大部分。此外,从开发视角进行建模,每每还会忽视业务人员的参与。而实践一再代表,资深的业务人员在领域建模时,每每能提出深刻的洞察。因此,从开发视角对领域模型进行建模绝对不可取。 ## 误区2: 创建庞大的领域模型 当咱们说“领域”的时候,并无限定一个“领域”应该有多大。到底是“航空”做为一个领域,仍是“航空”中的“订票”是一个领域? 当你考虑到“领域的核心是认知”,这个答案就变得很是清楚了。领域越大,越不利于创建认知和共识。咱们应该这问题域,把大的领域划分为小的领域,而后逐个创建这些小的领域的领域模型。那种整整一面墙的领域模型,每每都是不可取的。 ## 误区3: 重文档,轻交流和共识 领域模型的核心在于创建共同的共识,因此,若是只是把领域模型做为一种“制品”,做为某个阶段的“输出”,这是很是不合适的。领域模型须要做为交流工具。“统一语言”是避免该误区的重要方法。 ## 误区4: 不把领域模型显式化 不少人认为本身是有“认知”的,甚至是有“领域模型”的,可是,若是你问他们模型在哪里,这些要么就是在某个项目曾经有过一些讨论,可是如今已经不知所踪,要么就是虽然文档还在,可是团队的概念表达依旧混乱。没有显式化,没有把领域模型写下来,没有造成团队口口相传的知识,那么这种模型,并不真正存在。除了“统一语言”,咱们还有一个很是简便的检验方法,就是看这个团队如何给新人介绍本身的系统。由于领域模型反映了基本的业务概念,是一个很是好的新人培养工具,但凡真正有“领域模型”的组织,是不可能不把领域模型拿出来作介绍的。 # 总结 本文咱们主要介绍了领域模型的基本概念及重要度,领域模型对于“统一语言”的价值以及领域模型应用的常见误区。 总结一下要点: * 领域模型的本质是概念和认知,它定义了领域内的关键概念以及这些概念之间的关系 * 相对于业务的多变,领域模型相对稳定,优质的领域模型能够低成本的支持业务,领域模型也是统一语言的基础,能有效提高沟通效率 * 领域模型来自于业务滋养,领域模型生长的过程,也是业务认知创建的过程,协做建模是更有效的建模方法 在你的团队中,有显式的领域模型和共同的业务认知吗?它在指导平常的交流和开发工做吗?若是尚未,让咱们开始吧。 * 课程推荐:《DDD高手进阶12讲》 本文内容源自阿里云云效推出的《ALPD云架构师系列——DDD高手进阶12讲》。这是一门阿里内部的爆款课程,得到数千阿里工程师口碑推荐,值得每位开发者反复学习。 或PC端前往以下连接获取课程,免费领取阿里爆款架构师课程《DDD高手进阶12讲》(原价98元) https://developer.aliyun.com/topic/course/alpd > 本文内容由阿里云实名注册用户自发贡献,版权归原做者全部,阿里云开发者社区不拥有其著做权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。若是您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将马上删除涉嫌侵权内容。