DDD 基于时间的不变量答案

【问题标题】：DDD time-based invariantDDD 基于时间的不变量
【发布时间】：2017-06-24 18:08:05
【问题描述】：

我目前正在尝试将 DDD 实施到现有系统中，并且对我的一个模型的一些不变量有点头疼

在工资系统上工作时，一些不变量会在纳税年度开始时发生变化，但系统仍需要支持当前纳税年度。例如，如果目前最低全职工作年龄为 16 岁，但下一个纳税年度改为 15 岁，我可以通过 DDD 处理吗？

目前有一个参考数据存储库，它具有开始日期/到期日期，可以从使用当前日期读取以确定在给定日期使用的正确记录，但据我了解，使用模型中的存储库是有点不不。

我是否遗漏了 DDD 的一个明显点（例如，因为它需要一个存储库，它不是实体的不变量），还是有办法解决这个问题？（例如，当这种变化生效时，它们实际上是单独的聚合吗？）

【问题讨论】：

标签： domain-driven-design

【解决方案1】：

目前有一个参考数据存储库，它具有开始日期/到期日期，可以从使用当前日期读取以确定在给定日期使用的正确记录，但据我了解，使用模型中的存储库是有点不不。

使用存储库的真正问题是尝试访问某事物的“当前”状态，而不是与您正在做的工作同时发生变化。

从模型中访问 immutable 状态并没有根本性的问题；在讨论中，这通常表示为传递给模型的 DomainService（又名：“纯函数”），而不是存储库。

在您的情况下，税收政策不受您的模型控制；这是外界强加给你的东西；无论如何，您的模型所能做的最好的事情就是使用最新版本的策略历史记录。

简而言之，您将对时间进行建模，并且您将拥有一个域服务，该服务在给定时间后返回适合该时间的税收政策的不可变表示（状态）（据您所知），并且该模型将明确记录满足了哪个税收政策，而不仅仅是用于查找该政策的密钥。

【讨论】：

【解决方案2】：

如果您的聚合需要该时基信息，那么您必须提供它，无论它保存在何处。另一方面，聚合应该对外部服务有最小的依赖，你应该保持它们干净和纯净；所以聚合不应该做任何 IO，甚至不应该做一个抽象的（通过使用领域拥有并在基础设施中实现的接口）。

话虽如此，我会在调用聚合命令方法之前查询repository of reference data，并且我会将该信息作为值对象参数传递。所以，我不会在聚合中注入任何服务，甚至不会作为命令方法的参数。

换种方式思考：聚合是否关心信息存储在哪里，甚至是否存储在某个地方？不，它只需要信息，Application services 最擅长到达存储库并从那里加载所需的数据。

【讨论】：

【解决方案3】：

这是你应该工厂化的原因之一。例如，从您的案例来看，为就业合同建模非常有意义

现在你会得到这样的代码

public EmploymentContractFactory {

    public EmploymentContract(DateTime starttime, Person p) {
          if (starttime.Year == 2016 && p.Age < 16) {
             throw new TooYoungException();
          }
          else if (p.Age < 15) {
             throw new TooYoungException();
          }
          return new EmploymentContract(starttime, p);
    }
}

DDD 的理念是您的实体/工厂足够聪明，可以知道它们何时有效以及可以创建什么。

这在一定程度上取决于您要建模的内容/您的域的复杂性。例如，如果您的域处理了很多与合同相关的规则，您甚至可能有一个“ContractRule”，它可以根据您的模型合同评估某些法律。在这种情况下，您可以要求 Lawbook（聚合根）在特定日期返回所有适用的法律/规则，并使用您工厂中的法律/规则来查看您是否被允许创建该特定合同。

【讨论】：