DDD中的参考数据

Question

作为我开始DDD之旅的previous question的后续跟踪，我在项目代码的开票上下文中有一些参考数据，这些参考数据在配置上下文中管理。数据的一个子集从配置镜像到开票（Id，Name），我需要加载此信息，以便在有人创建发票时验证项目代码是否存在。

我是否应该将此商品代码参考数据建模为开票上下文中的聚合根？这似乎有点过分＆＃39;对我来说，因为你永远不会在发票上下文中更新项目代码，但是关于DDD的大多数指导都指出只应从存储库加载聚合。

我正在考虑宣布一个查找＆＃39;加载实体的存储库（因为它们有ID，因此不会是值对象，我假设？），而不是每组参考数据的存储库。这是可以接受的吗？

Answer 1

  

我正在考虑声明一个加载实体的“查找”存储库（因为它们有ID，因此不会是值对象，我假设？），而不是每组参考数据的存储库。这是可以接受的吗？

这是正确的想法，但你使用的拼写并不是很明确。您正在寻找的概念是域服务，而不是存储库。

  

如果有人正在创建发票，我需要加载此信息以验证项目代码是否存在。

如果商品代码的权限是其他地方，并且您的发票模型需要知道商品代码是否存在，那么通常的模式是拥有您传递给模型的域服务。域服务提供功能来查找项目代码，域模型决定何时需要该功能。

// choose a spelling that is compatible with your naming conventions
// for domain services.
interface ItemCodes {
    boolean exists(ItemCode itemCode);
}

// In your domain model, the use looks like
class InvoiceModel {
    void createInvoice(..., ItemCodes itemCodes, ....) {
        //...

        if (! itemCodes.exist(code) ) {
            ...
        }
    }
}

实施细节 - 如何检查项目代码是否存在 - 位于应用程序服务或实现域服务合同的基础结构服务中。

有关域名服务的更多信息，请查看the blue book的第5章。

  

我曾想过要创建一个基础结构服务来进行检查，但是想知道这是否是一种可接受的方法。在这个基础结构服务类中包含数据访问逻辑是否可以接受，或者我是否还应该拥有一个存储库类句柄？

不同抽象层的部分动机是我们可以隐藏实现细节。这意味着我们可以自由地改变它们。根据您对问题的描述，我可能只是在基础架构类中使用原始数据访问逻辑，知道如果我们以后发现它需要更多的存储库，就像语义一样，我们可以改变实现。