在蓝皮书第15章“蒸馏”中,埃里克·埃文斯谈到了一种他称之为内聚机制的模式。该章多次提到,框架的功能应该通过意图揭示界面(第10章)来展示。例如,我引用
DDD Reference
:
将概念上有凝聚力的机制划分为一个单独的轻量级框架。特别要注意形式主义或记录良好的算法类别。通过意图揭示界面展示框架的功能。现在,该领域的其他元素可以专注于表达问题(“什么”),将解决方案的复杂性(“如何”)委托给框架。
书中给出的例子是关于作为内聚机制实现的图遍历框架的一个子集,封装了执行会混淆领域的计算所需的算法,这是关于组织图而不是图论。Eric说,该框架暴露了一个意图揭示界面,但我很困惑该界面是使用领域语言、组织结构图,还是使用图论语言的意图揭示界面。
我在一个正在开发的软件中有自己的例子。它需要创建一组文档,其中包含一些详细的规则和验证,用户将打印出来。域模型的实现讨论了这些文档中的概念,并试图以我们可以实现的更清晰的方式来表达规则(这里不断改进)。每个文档都有一个具有域含义的id号,但只要用户正在起草这些文档,就可以根据一些规则重新排列和丢弃这些编号,直到草稿被“接受”为有效。重新排列数字所需的计算有点复杂和复杂,模糊了与数字本身无关的模型(尽管计算很重要)。
我认为这是一个应用该模式的好例子,因此我们可以单独测试“框架”,以验证复杂的计算,同时我们可以将模型的其余部分从它们产生的混乱中解放出来。
所以问题是:
当这本书谈到模式时,他说应该用一个意图揭示界面来展示它,这个界面是谈论计算所提取的模型的语言(组织图;文档和规则),还是谈论机制本身的语言(图论;数字和重排)?
当然,我们不应忘记实用主义,我们将测试一些选择,保持看起来更干净、工作表现更好的选择;然而,当我在阅读这一章以寻找灵感时,这个问题让我很困扰,我无法从文本中回答它(或者我没有看对地方)。
