DDD中的参考数据

Question

作为我上一个DDD旅程的上一个问题的后续，我在“发票”上下文中有一些关于项目代码的参考数据，这些参考数据在“配置”上下文中进行管理。 数据的一部分从配置镜像到发票（编号，名称），如果有人创建发票，我需要加载此信息以验证是否存在项目代码。

我应该在发票环境中将此物料代码参考数据建模为汇总根吗？ 在我看来，这有点“过大杀伤力”，因为您永远都不会在“发票”上下文中更新商品代码，但是有关DDD的大多数指南都指出，应该仅从存储库加载聚合。

我当时正在考虑声明一个“查找”存储库，该存储库可加载实体（因为它们具有ID，所以我认为不会是一个Value Object？），而不是每个参考数据集的存储库。 这是可以接受的吗？

Answer 1

我当时正在考虑声明一个“查找”存储库，该存储库可加载实体（因为它们具有ID，所以我认为不会是一个Value Object？），而不是每个参考数据集的存储库。 这是可以接受的吗？

这是正确的主意，但您使用的拼写不太准确。 您正在寻找的概念是域服务 ，而不是存储库 。

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

如果“项目代码”的权限位于其他地方 ，并且您的“进销存模型”需要知道某个项目代码是否存在，则通常的模式是将域服务传递给模型。 域服务提供了查找项目代码的能力 ，域模型确定何时需要该能力。

// 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) ) {
            ...
        }
    }
}

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

有关域服务的更多信息，请查看蓝皮书的第5章。

我曾想过要创建一个基础结构服务来进行检查，但想看看这是否可以接受。 在此基础结构服务类中包含数据访问逻辑是否可以接受，还是我应该还有一个存储库类来处理呢？

不同抽象层的部分动机是我们可以隐藏实现细节。 这意味着我们可以自由更改它们。 从问题的描述中，我可能会只在基础结构类内部使用原始数据访问逻辑，因为如果我们以后发现它需要更多的存储库（如语义），我们可以更改实现。