本节书摘来自异步社区《领域驱动设计：软件核心复杂性应对之道（修订版）》一书中的第2章，第2.5节解释性模型，作者【美】埃里克•埃文斯（Eric Evans）, 马利伟 , 万龙，更多章节内容可以访问云栖社区“异步社区”公众号查看。
2.5 解释性模型
本书的核心思想是在实现、设计和团队交流中使用同一个模型作为基础。如果各有各的模型，将会造成危害。
模型在帮助领域学习方面也具有很大价值。对设计起到推动作用的模型是领域的一个视图，但为了学习领域，还可以引入其他视图，这些视图只用作传递一般领域知识的教学工具。出于此目的，人们可以使用与软件设计无关的其他种类模型的图片或文字。
使用其他模型的一个特殊原因是范围。驱动软件开发过程的技术模型必须经过严格的精简，以便用最小化的模型来实现其功能。而解释性模型则可以包含那些提供上下文的领域方面——这些上下文用于澄清范围更窄的模型。
解释性模型提供了一定的自由度，可以专门为某个特殊主题定制一些表达力更强的风格。领域专家在一个领域中所使用的视觉隐喻通常呈现了更清晰的解释，这可以教给开发人员领域知识，同时使领域专家们的意见更一致。解释性模型还可以以一种不同的方式来呈现领域，并且各种不同角度的解释有助于人们更好地学习。
解释性模型不必是对象模型，而且最好不是。实际上在这些模型中不使用UML是有好处的，这样可以避免人们错误地认为这些模型与软件设计是一致的。尽管解释性模型与驱动设计的模型往往有对应关系，但它们并不完全类似。为了避免混淆，每个人都必须知道它们之间的区别。
示例 航运操作和路线
考虑一个用来追踪航运公司货物的应用程序。模型包含一个详细的视图，它显示了如何将港口装卸和货轮航次组合为一次货运的操作计划（“路线”）。如图2-4所示。但对外行而言，类图可能起不到多大的说明作用。
在这种情况下，解释性模型可以帮助团队成员理解类图的实际含义。图2-5是表示相同概念的另一种方式。
图中的每根线段都表示货物的一种状态——或者正在港口装卸（装货或卸货），或者停放在仓库里，或者正在运输途中。这个图并没有与类图中的细节一一对应，但强调了领域的要点。
42
这种图连同对它所表示的模型的自然语言解释，能够帮助开发人员和领域专家理解更严格的软件模型图。综合使用这两种图要比单独使用一种图更容易理解。
43
① 清关即结关，习惯上又称通关，是指进口货物、出口货物和转运货物进出一国海关或国境时必须向海关申报，办理海关规定的各项手续，履行各项法规规定的义务。——译者注
本文仅用于学习和交流目的，不代表异步社区观点。非商业转载请注明作译者、出处，并保留本文的原始链接。
