【编程思想】运用领域模型

举报
G-washington 发表于 2020/02/14 19:49:38 2020/02/14
【摘要】 每个软件程序是为了执行用户的某项活动,或是满足用户的某种需求。这些用户应用软件的问题区域就是软件的领域。一些领域涉及物质世界,例如,机票预订程序的领域中包括飞机乘客在内。有些领域则是无形的,例如,会计程序的金融领域。软件领域一般与计算机关系不大,当然也有例外,例如,源代码控制系统的领域就是软件开发本身。

上面这张图是18世纪中国描绘的世界地图。图中央最大的部分是中国,其周围散布着其他国家,但这些国家只是草草地表示了一下。这是适用于当时中国社会的世界模型,它意在关注中国自身。然而,这幅地图所呈现的世界观对于处理外交事务并无助益。当然,它对现代中国也毫无用处。地图就是模型,而模型被用来描绘人们所关注的现实或想法的某个方面。模型是一种简化。它是对现实的解释——把与解决问题密切相关的方面抽象出来,而忽略无关的细节。

每个软件程序是为了执行用户的某项活动,或是满足用户的某种需求。这些用户应用软件的问题区域就是软件的领域。一些领域涉及物质世界,例如,机票预订程序的领域中包括飞机乘客在内。有些领域则是无形的,例如,会计程序的金融领域。软件领域一般与计算机关系不大,当然也有例外,例如,源代码控制系统的领域就是软件开发本身。


image.png

为了创建真正能为用户活动所用的软件,开发团队必须运用一整套与这些活动有关的知识体系。所需知识的广度可能令人望而生畏,庞大而复杂的信息也可能超乎想象。模型正是解决此类信息超载问题的工具。模型这种知识形式对知识进行了选择性的简化和有意的结构化。适当的模型可以使人理解信息的意义,并专注于问题。

领域模型并非某种特殊的图,而是这种图所要传达的思想。它绝不单单是领域专家头脑中的知识,而是对这类知识严格的组织且有选择的抽象。图可以表示和传达一种模型,同样,精心书写的代码或文字也能达到同样的目的。

领域建模并不是要尽可能建立一个符合“现实”的模型。即使是对具体、真实世界中的事物进行建模,所得到的模型也不过是对事物的一种模拟。它也不单单是为了实现某种目的而构造出来的软件机制。建模更像是制作电影——出于某种目的而概括地反映现实。即使是一部纪录片也不会原封不动地展现真实生活。就如同电影制片人讲述故事或阐明观点时,他们会选择素材,并以一种特殊方式将它们呈现给观众,领域建模人员也会依据模型的作用来选择具体的模型。

模型在领域驱动设计中的作用

在领域驱动的设计中,3个基本用途决定了模型的选择。

(1) 模型和设计的核心互相影响。正是模型与实现之间的紧密联系才使模型变得有用,并确保我们在模型中所进行的分析能够转化为最终产品(即一个可运行的程序)。模型与实现之间的这种紧密结合在维护和后续开发期间也会很有用,因为我们可以基于对模型的理解来解释代码。

(2) 模型是团队所有成员使用的通用语言的中枢。由于模型与实现之间的关联,开发人员可以使用该语言来讨论程序。他们可以在无需翻译的情况下与领域专家进行沟通。而且,由于该语言是基于模型的,因此我们可借助自然语言对模型本身进行精化。

(3) 模型是浓缩的知识。模型是团队一致认同的领域知识的组织方式和重要元素的区分方式。透过我们如何选择术语、分解概念以及将概念联系起来,模型记录了我们看待领域的方式。当开发人员和领域专家在将信息组织为模型时,这一共同的语言(模型)能够促使他们高效地协作。模型与实现之间的紧密结合使来自软件早期版本的经验可以作为反馈应用到建模过程中。

软件的核心

软件的核心是其为用户解决领域相关的问题的能力。所有其他特性,不管有多么重要,都要服务于这个基本目的。当领域很复杂时,这是一项艰巨的任务,要求高水平技术人员的共同努力。开发人员必须钻研领域以获取业务知识。他们必须磨砺其建模技巧,并精通领域设计。

然而,在大多数软件项目中,这些问题并未引起足够的重视。大部分有才能的开发人员对学习与他们的工作领域有关的知识不感兴趣,更不会下力气去扩展自己的领域建模技巧。技术人员喜欢那些能够提高其技能的可量化问题。领域工作很繁杂,而且要求掌握很多复杂的新知识,而这些新知识看似对提高计算机科学家的能力并无裨益。

相反,技术人才更愿意从事精细的框架工作,试图用技术来解决领域问题。他们把学习领域知识和领域建模的工作留给别人去做。软件核心的复杂性需要我们直接去面对和解决,如果不这样做,则可能导致工作重点的偏离。


一个例子


在一次电视访谈节目中,喜剧演员John Cleese讲述了电影《巨蟒和圣杯》(Monty Python and the Holy Grail)在拍摄期间发生的一个小故事。有一幕他们反复拍了很多次,但就是感觉不够滑稽。最后,他停下来,与另一位喜剧演员Michael Palin(该幕中的另一位演员)商量了一下,他们决定稍微改变一下。随后又拍了一次,终于令他们满意了,于是收工。

第二天早上,Cleese观看了剪辑人员为前一天工作所做的粗剪。到了那个令他们颇费周章的场景时,Cleese发现剪辑人员竟然使用了先前拍摄的一个镜头,影片到这里又变得不滑稽了。

他问剪辑人员为什么没有按要求使用最后拍的那个镜头,剪辑人员回答说:“那个镜头不能用,因为有人闯入了镜头。”Cleese连看了两遍,仍未发现有什么不妥。最后,剪辑人员将影片暂停,并指出在屏幕边缘有一只一闪而过的大衣袖子。

影片的剪辑人员专注于准确完成自己的工作。他担心其他看到这部电影的剪辑人员会给他挑错。在这个过程中,镜头的核心作用被忽略了(“The Late Late Show with Craig Kilborn”,CBS,2001年9月)。

幸运的是,该剧的导演很懂喜剧,他最终使用了那个镜头。同样,在一个团队中,反映了对领域深层次理解的模型开发有时也会在混乱中迷失方向,此时,理解领域核心的领导者能够将软件项目带回到正确的轨道上来。


image.png

大多数混乱的软件领域其实是一项充满乐趣的技术挑战。事实上,在许多科学领域中,“复杂性”都是当前最热门的话题之一,因为研究人员都在想办法解决真实世界中的复杂性。软件开发人员在面对尚未规范的复杂领域时,也会有同样的期望。创建一个克服这些复杂性的易懂模型会带来巨大的成就感。

开发人员可以采用一些系统性的思考方法来透彻地理解领域并开发出有效的模型。还有一些设计技巧可以使毫无头绪的软件应用变得井井有条。掌握这些技能可以令开发人员的价值倍增,即使是在一个最初不熟悉的领域中也是如此。


本文节选自《领域驱动设计:软件核心复杂性应对之道(修订版)》


内容简介


本书是领域驱动设计方面的经典之作,修订版更是对之前出版的中文版进行了全面的修订和完善。

全书围绕着设计和开发实践,结合若干真实的项目案例,向读者阐述如何在真实的软件开发中应用领域驱动设计。书中给出了领域驱动设计的系统化方法,并将人们普遍接受的一些最佳实践综合到一起,融入了作者的见解和经验,展现了一些可扩展的设计最佳实践、已验证过的技术以及便于应对复杂领域的软件项目开发的基本原则。

本书适合各层次的面向对象软件开发人员、系统分析员阅读。

本文转载自异步社区

原文链接:https://www.epubit.com/articleDetails?id=NC7E3EF9194F00001D5341B201EF09CF0

【版权声明】本文为华为云社区用户转载文章,如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容,举报邮箱: cloudbbs@huaweicloud.com
  • 点赞
  • 收藏
  • 关注作者

评论(0

0/1000
抱歉,系统识别当前为高风险访问,暂不支持该操作

全部回复

上滑加载中

设置昵称

在此一键设置昵称,即可参与社区互动!

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。

举报
请填写举报理由
0/200