领域驱动设计-读书笔记-第九章-将隐形概念转变为显性概念

背景以及问题

什么是深层建模？深层建模包含了领域的核心概念，能够以最灵活简单的方式呈现出解决方案。深层建模第一步是要设法在模型中表达出领域的基本概念，随后在不断消化知识和重构过程中，实现模型的精化。

如何实现深层建模呢？

这是个比较大的话题。但是，一般开始深层建模的征兆是：我们可以识别出某个重要概念并且在模型把它显示的表达出来。

概念挖掘

示例：听出运输模型中缺失的概念

例子：团队已经开发出了可用来预订货物的有效应用程序。现在他们开始开发“作业支持”应用程序，此程序可帮助工作人员管理工作单，这些工作单用于安排起始地和目的地的货物装卸以及在不同货轮之间转运时需要的货物装卸。

对话：

领域专家反馈表中缺少日期，讨论出缺少一个航海日程概念。航海日程实际上把预订程序和作业程序连接起来了。在每段行程中，我们都希望看到船名航次、装货和卸货地点以及时间。所以，我们一旦创建了Leg（般段）对象，就能够从航次安排中获取时间信息。我们可以将Itinerary（航海日程）对象作为与作业应用程序联系的主要连接点。同时，还可以用这种方式重新编写航海日程报表，这样领域逻辑就重新回到领域层中了。

如下，新的模型：

把显式的Itinerary对象作为模型的一部分，带来了深入挖掘模型的机会，最终呈现出了深层建模带来的核心模型。

检查不足之处（积极深入发掘和探索）

有些概念并非是能通过沟通或者对话显现出来，需要自己深入挖掘和创造。有时候很难意识到模型中缺失了什么，但是整体模型不够精简，职责实现很笨拙，这个时候一个办法是，积极的让领域专家参与进来，同时自己进一步发掘和探索。

示例：摸索利息计算模型

该公司经营商业贷款和其他一些生息资产。公司开发了一个用于跟踪这些投资及收益的应用程序，通过一项一项地添加功能来使它不断地发展。每天晚上，公司都会运行一个批处理脚本，用于计算当天所生成的利息和费用，并把它们相应地记录到公司的财务软件中。

晚间批处理脚本会遍历每笔Asset（资产），并让其执行calculateInterestForDate()，按照当天的日期来计算利息。然后，该脚本会接收返回值（收益金额），并将它和指定分类账的名称一起发送给一个SERVICE（这个SERVICE提供了记账程序的公共接口）。再由记账软件将收入金额过账到指定的分类账中。这个脚本还会对每笔Asset当日的手续费作类似的处理，并记录到另一个不同的分类账中。

自己提炼下：有一个Asset资产模型，此模型提供了两个接口，一个是计算利息，一个是计算费用。计算利息的接口依赖Fee Calculator，并生成Fee Payment History，计算费用的接口依赖Interest Calculator，并生成Interest Payment History。这种模型设计方法，其实在我们的开发中非常常见。

深入探讨的对话：

开发人员：Interest Calculator 利息计算器太复杂了。如果没有按时支付利息该如何处理？比如追踪会计期内到期未付利息，这种利息有名字吗？

业务专家：引出 应计制会计。由于领域驱动设计这个书上说的太模糊了，自己百度了下，即：应计制又称权责发生制或应收应付制。它确定本期收入和费用，以应收应付作为标准。也就是说，凡属于本道期已获得的收入，不管其款项是否收到，都应作为本期的收入处理；凡属本期应当负担的费用，不论款项是否付出，都应作为本期的费用处理。反之，凡不归属本期的收入版，即使其款项已经收到并入账，也不作为本期的收入处理；凡不应归属本期的费用，即使款项已经付出并入账，也不作为权本期的费用处理。由于它不问款项的收付，而以收入和费用应否归属本期为准，说以称为应计制。

开发人员：使用应计制后，其实不用care利息有没有具体付，只要是产生的利息就应该记录下来。

新的模型，完全采用应计制进行计算。一笔Asset（资产）对应多笔Payment，对应多笔Income Accrual (收入应计）。

程序会定期执行，输入模型数据（Payment模型，Income Accrual收入应计模型）根据分类的账目不同，执行Accrual Schedule (应计调度），将不同类型的账目，计入Compound Interest (利息记录），Monthly Fee (月费用记录）。

好处：

提炼出领域术语，Accrual。

领域知识从脚本中分离出来，分类到不同的领域模型中。

应计费用不再有payment承担，分离到income accrual。

新的形式的利息和费用都可以很好的通过accrual scheduler记录到不同的分账中。

查阅书籍（积极深入发掘和探索）

查阅书籍也许能够使你一开始就形成一致且深层的认识。

示例：还是上文的利息计算模型

作者从书中得知，应计制会计。这种方法把所有已经产生的收入均计到收入中（即使尚未支付），所有支出也均在产生时显示出来（无论是已经支付还是以后才支付）。所有到期债务，包括税金，都列入费用。

不过这种得到这种认知的概率还是较低，还是前提多与领域专家进行深入的探索和交流。

如何为哪些不太明显的概念建模

显式的约束

如果约束的存在掩盖了对象的基本职责，或者如果约束在领域中非常突出但在模型中却不明显，那么就可以将其提取到一个显式的对象中，甚至可以把它建模为一个对象和关系的集合。

下面是一些警告信号，表明约束的存在正在扰乱其“宿主对象”（HostObject）的设计。
        (1) 计算约束所需的数据从定义上看并不属于这个对象。
        (2) 相关规则在多个对象中出现，造成了代码重复或导致不属于同一族的对象之间产生了继承关系。
        (3) 很多设计和需求讨论是围绕这些约束进行的，而在代码实现中，它们却隐藏在过程代码中。

示例 复核：超订策略

预订超出运输能力10%的货物。（货运公司的经验表明，这种程度的超定可以抵消因客户临时取消订单而空出来的舱位，这样货轮基本能够满载起航。）

将过程建模为领域对象

过程是应该被显式表达出来，还是应该被隐藏起来呢？区分的方法很简单：它是经常被领域专家提起呢，还是仅仅被当作计算机程序机制的一部分？约束和过程是两大类模型概念，当我们用面向对象语言编程时，不会立即想到它们，然而它们一旦被我们视为模型元素，就真的可以让我们的设计更为清晰。

规格”提供了用于表达特定类型的规则的精确方式，它把这些规则从条件逻辑中提取出来，并在模型中把它们显式地表示出来。

业务规则通常不适合作为ENTITY或VALUE OBJECT的职责，而且规则的变化和组合也会掩盖领域对象的基本含义。但是将规则移出领域层的结果会更糟糕，因为这样一来，领域代码就不再表达模型了。逻辑编程提供了一种概念，即“谓词”这种可分离、可组合的规则对象，但是要把这种概念用对象完全实现是很麻烦的。解决方案：SPECIFICATION（规格）中声明的是限制
另一个对象状态的约束，被约束对象可以存在，也可以不存在。SPECIFICATION有多种用途，其中一种体现了最基本的概念，这种用途是：SPECIFICATION可以测试任何对象以检验它们是否满足指定的标准。

为特殊目的创建谓词形式的显式的VALUE OBJECT。SPECIFICATION就是一个谓词，可用来确定对象是否满足某些标准。

SPECIFICATION作用：

(1) 验证对象，检查它是否能满足某些需求或者是否已经为实现某个目标做好了准备。
       (2) 从集合中选择一个对象（如上述例子中的查询过期发票）。
       (3) 指定在创建新对象时必须满足某种需求。

示例 化学品仓库打包程序

假设有一个仓库，里面用类似于货车车厢的大型容器存放各种化学品。有些化学品是惰性的，可以随意摆放。有些则是易挥发的，必须放于特制的通风容器中。还有一些是易爆品，必须保存于特制的防爆容器中。还有一些规则是关于如何在容器中混装化学品的。

 

总结

回到开头的话题，如何深层建模，提炼一下：

• 深入挖掘，与领域专家沟通，听出领域模型中缺失的关键概念。
• 抛出疑问，带着重构的思想，深入检查不足之处，提炼出新的领域术语，对模型进一步深层次改造。
• 查阅书籍，了解对应的领域术语。
• 为不明显的概念建模，创建显示约束，将过程模型设计转变为模型驱动设计，利用specification对业务规则进行限制。