《领域驱动设计：软件核心复杂性应对之道（修订版）》—第1章 1.5节深层模型

本节书摘来自异步社区《领域驱动设计：软件核心复杂性应对之道（修订版）》一书中的第1章，第1.5节深层模型，作者【美】埃里克•埃文斯（eric evans）, 马利伟 , 万龙，更多章节内容可以访问云栖社区“异步社区”公众号查看。

1.5　深层模型

有用的模型很少停留在表面。随着对领域和应用程序需求的理解逐步加深，我们往往会丢弃那些最初看起来很重要的表面元素，或者切换它们的角度。这时，一些开始时不可能发现的巧妙抽象就会渐渐浮出水面，而它们恰恰切中问题的要害。

前面的例子大体上是基于一个集装箱航运项目，这是本书列举的几个项目之一，本书还有几个示例会引用这个项目。本书所举的示例都很简单，即使不是航运专家也能理解它们。但在一个需要团队成员持续学习的真实项目中，要想建立实用且清晰的模型则要求团队成员既精通领域知识，也要精通建模技术。

在这个项目中，由于航运从预订货运开始，因此我们开发了一个能够描述货物和运货航线等事物的模型。这是必要且有用的，但领域专家却不买账。他们有自己的考虑业务的方式，这种方式是我们没有考虑到的。

最后，在经过几个月的知识消化后，我们知道货物的处理主要是由转包商或公司中的操作人员完成的，这包括实际的装货、卸货和运货。航运专家的观点是，各部分之间存在一系列的责任传递。法律责任和执行责任的传递由一个过程控制——从托运人传递到某个本地运输商，再从这家运输商传递到另一家运输商，最后到达收货人。通常，在一些重要的步骤中，货物停放在仓库里。在其他时间里，货物则是通过复杂的物理步骤来运输，而这些与航运公司的业务决策无关。在处理航线的物流之前，必须先确定诸如提单等法律文件以及支付流程。

20

对航运业务有了更深刻的认识后，我们并没有删除itinerary（航线）对象，但模型发生了巨大改变。我们对航运业务的认识从“集装箱在各个地点之间的运输”转变为“运货责任在各个实体之间的传递”。处理这些责任传递的特性不再是一些附属于装货作业的次要特性，而是由一个独立的模型来提供支持，这个模型正是在理解了作业与责任之间的重要关系之后开发出来的。

知识消化是一种探索，它永无止境。

21

① 走查，walk through，原来是指一种非正式的代码评审活动，现在也广泛用于其他方面，一般是指一步步检查或分步讨论。——译者注

② 卫语句，guard clause，指起保护作用的语句。——译者注

③ strategy一般是指定义一组算法，将每个算法都封装起来，并且使它们之间可以互换。策略模式的优点是软件可以由许多可替换的部分组成，各个部分之间是弱连接的关系，这样软件具有更强的可扩展性、可维护性和可重用性。作者在这里提到策略模式，是指将每个规则当成一个算法。——译者注

本文仅用于学习和交流目的，不代表异步社区观点。非商业转载请注明作译者、出处，并保留本文的原始链接。