规范模式与实体内部领域逻辑的维护

Question

我想了解更多关于规范模式的信息，正如Eric的书““领域驱动设计””中所描述的那样。

Evans提出的要点之一是，域模型包含所有重要的业务规则(逻辑和行为)。

本书中的DDD战术模式描述了如何使用实体和集合以面向对象的方式封装领域知识。

规范模式有助于将一段领域知识封装到一个单元中。

如果我想使用规范模式，并且对它有不同的用途，并且在几个地方评估一个常量逻辑，比如在Application之前作为输入验证，在实体内部作为不变量，但是如果我想将域逻辑保存在它的内部，我应该如何实现它？

在我看来，规范似乎不是一种可以与DDD方法和OOP范式一起使用的模式，它对于函数式编程范式更有用。

我的理解正确吗？

Answer 1

很容易忽略规范的概念是什么，因为有那么多糟糕的文章漂浮在网络上。

在编辑该问题之前，您最初写道：

另一方面，DDD说，这个领域的知识或逻辑必须在实体本身内。

艾米，不。实体并不是领域模型中唯一能够携带领域知识的元素。Value对象也可以，Evan的DDD书中描述的规范对象也是值对象--特别是带有布尔逻辑的值对象。实体和相关的价值对象形成聚合，这是领域知识存在的地方。

我建议从Martin和Evans编写的关于“规范”的这篇有20年历史的文章开始，主要是作为一种分析模式，并为可能的实现提供一些建议，从而增强您的理解。

对于简单的情况，Specification可以简单地看作是某种帮助对象。当您看到需要从域实体中重构某些布尔逻辑时，它们可能会出现，例如，因为您想要对抗某个实体成为“上帝对象”，或者因为您看到了创建一个对象的机会，在该对象中，可以单独测试一个片段逻辑。然而，规范本身并不具有标识，它属于某个域实体，即使代码不是放在同一个类中。这就是前一篇文章所说的“硬编码规范”。

逻辑可能不是完全硬编码的，它也可以通过使用策略模式实现Specification或引入一些参数(本文称之为“参数化规范”)在运行时进行交换。

对于更复杂的情况，像“复合规范”这样的实现可能是有用的。这个维基百科文章展示了一个可能的实现。这里一个令人困惑的地方是，它只是将其称为“规范模式”。这个标题肯定太笼统了，或者说文章本身太具体了，因为它只展示了复合方法。另一个令人困惑的部分是，它为所需的框架提供了大量代码，而没有明确说明复合规范的目的。这种复杂方法的好处是能够在运行时自由地修改某些业务规则。因此，它可以通过来自某个用户的输入或配置，或者由某些外部数据源进行修改。这一好处来自于必须构建和使用围绕着它的“复合元素”的迷你框架的代价。

“复合规范”本质上是一种通过标准条件组合谓词(布尔函数)的方法，而不是在运行时组合。您正确地注意到:这确实是一项功能任务，与纯OO方法相比，它肯定可以以更少的代码和更少的开销来实现。

仍然可以在OO和/或DDD上下文中创建规范对象。20年后的今天，功能元素在大多数主要编程语言中变得越来越流行。因此，我认为应该可以很容易地使用多范式方法，并在域模型中使用更高级的函数或闭包来实现规范，而不是普通的值对象。不过，这将是DDD和OO (与一些功能“好东西”)，我没有看到任何矛盾的这一点。