领域建模概述

2023-10-30

0 概述

在软件工程中，有两个高阶的工作的分别是架构和建模；如果把写代码比喻成施工，那么架构和建模就是设计图纸。相比编码，那么建模的确是对设计经验和抽象能力要求更高的一种技能。本文主要探讨一下对领域建模相关知识的理解。

1 什么是领域建模

1.1 什么是领域

维基百科给出的定义：A sphere of knowledge，influence, or activity. The subject area to which the user applies a program is the domain of the software[1]；一个特定范围的知识、影响或者活动，这个主题域应用到程序上就是这个软件系统的领域。重点强调了特定范围，范围即边界；既然领域是用来限定业务边界和范围的，那么就会有大小之分，领域越大，业务范围越大；如下图所示子商务领域；电商领域是一个比较大的领域，通常的做法就是将问题一步一步地细分&拆解，再针对细分出来的子问题域，逐个深入研究，探索和建立所有的子问题域的知识体系。
在这里插入图片描述
案例：

那到底是穿多还是穿少呢？如果说场景是在一个炎热的夏天或者寒冬腊月

1.2 什么是领域模型

定义**：领域模型**(domain model)是对领域内的概念类或现实世界中对象的可视化表示，也称他为概念模型和分析模型。领域模型是问题域模型；值得强调是领域模型这一术语是多义的，也用来表示软件对象的领域层，在表示层或者UI层之下的软件对象层是由领域对象组成；领域对象是表示问题域空间事物的软件对象，并且与业务逻辑或领域逻辑方法相关[2]。定义关键点：1）“领域内”，领域是特定范围，即边界，也就是说领域模型是针对某个问题域而言；脱离特定边界与范围领域模型是没有意义的。2）领域模型是抽象的，不是对某个问题的各个相关方面的一个映射，也不是解决方案的构建。
如下图所示，汽车领域模型表示；值得说明的是：这个模型是对真实世界的问题域描述，反映的是问题空间的本质理解，不是对软件设计的描述，它和技术无关。
在这里插入图片描述

不难发现在解决方案空间的领域模型和概念模型命名上差不多，但是它们不是一回事，但是前者对后者名称和定义有着启发的作用；这样好处是可以减小我们思维与软件模型之间的表示差异。从上面的案例不难看出，领域模型的好处：1）简化了认知，统一思想，避免开发人员与业务方的认知差异；2）易于知识的传递。

1.3 什么是领域建模

在理解领域建模之前，我们先思考下软件开发的本质，软件开发本质就是从从问题空间到解决方案空间的一个映射转化，如下图所示。在问题空间中，就是系统要解决的的领域问题（找出某个业务面临的挑战以及相关用例的分析）;在解决方案空间中，则是通过具体的技术工具手段进行设计实现。
在这里插入图片描述

定义：领域建模也叫业务建模，是针对我们需要解决的问题空间，使用特定的方法，进行抽象，分析，并产出业务概念模型的过程。值得强调的是领域建模首先是一个定义问题方法，其次才是解决问题的方法。我们很容易理解解决问题带来的价值，很容易忽略定义问题的力量。要想有效定义问题，就要从业务出发，首先尝试在业务中寻找简化问题的可能性，然后在技术中寻找对应的解决方案。

1.4 模型不能代替现实

模型毕竟是模型，不能代替现实；建模的过程与建模者的观察角度和对问题认知有直接关系，所以我们要从认知的角度和发展的眼光去看待模型。如下图所示科学发展过程是一个不断否定和逐步求精的过程。
在这里插入图片描述
模型在软件开发中作用也类似，我们也要用发展的眼光来看待模型，没有一步到位，建模也要符合问题发展的阶段和背景；随着业务的和认知的提升，模型也要不断升级，确保它能够跟上我们对问题域最新理解。如下图TCP发展历程，也是一个不断演进的过程。
在这里插入图片描述

2 为什么要学习领域建模

2.1 从个人发展来看

武侠⼩说中的武功分为剑法（招式）和内功，内外兼修才是王道！技术就像武功，编程语⾔和框架这些都是剑法，领域建模就是所谓的内功⼼法。
在这里插入图片描述

2.2 从业务系统开发来看

领域模型对于业务系统是更好的选择，我们知道软件开发的核心难度在于处理隐藏在业务知识中的复杂度，这种复杂度是必然的复杂度，而模型就是对这种复杂度的简化与精炼。 DDD作者Eric倡导的领域驱动设计是一种模型驱动的设计方法：通过领域模型捕捉领域知识，使用领域模型构造更易维护的软件。如下图所示，在软件行业发展的早期，人们习惯将将问题转化为与具体领域的无关的模型（堆、栈、链表、树、图等数据结构）并解决了大量的基础软件的问题。究竟是将问题转化业务强相关还是与具体问题无关，这个关键的差异体现在人上，对于业务软件而言，从业务出发去构造与业务强相关的模型，是一种更好的选择
。
在这里插入图片描述

3 领域建模的难点

业务建模很多种，常用有以下几种

E-R
OOA/OOD
DDD
业务建模难度本身不在于使用建模方法本身，真正的难点
清晰的定义的业务问题，并让所有干系人都能接受你对业务问题定义。这里所说的定义业务问题：是指对业务问题的梳理和总结，明确对业务的影响以及产出。需要提炼和总结，并通过所选用的业务建模方法中蕴含的逻辑框架去验证它。这里挑战就不仅仅是建模的本身了，而在于如何获取业务方的信任，并展开有效的讨论。
在特定架构约束下，将模型实现出来。我们在学习建模方法时候，往往会不自觉的忽略架构对模型的影响。于是可能大概率会出现一种现象：学会了一种建模方法，却因为不知道怎么处理架构约束，而无法将其应用到实际工作中。

4 总结

领域建模给人的感觉就是一学就会，一用就废；主要原因大家缺少实践；所以要想真正学好领域建模，必须要知行合一。

参考文献
【1】https://en.wikipedia.org/wiki/Domain_(software_engineering)
【2】uml和模式应用（第三版），机械工业出版社。
【3】https://en.wikipedia.org/wiki/Conceptual_model_(computer_science)
【4】https://time.geekbang.org/column/intro/100082101?tab=catalog
【5】实现领域驱动设计
【6】代码精进之路：从码农到工匠，张建飞
【7】解构领域驱动设计

本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)