domain-driven-design - 是否可以根据服务拥有一个存储库？

Question

我正在从事一个涉及版本控制实体的项目，以便将用户修改的整个历史记录存档。

基本上，这个想法是当一个实体被创建时，其内容的版本 1 也被保存在一个归档表中。每当修改实体时，也会存储增量版本。

将实体的状态保存到存档表由 ArchiveService 处理。

当实体被持久化时，需要调用 ArchiveService 来创建版本 1，因此最合乎逻辑的方法似乎是从存储库中调用它，从而将服务作为依赖项传递给存储库:

public class Repository {
    private ArchiveService archiveService;

    public Repository(ArchiveService service) {
        this.archiveService = service;
    }

    public void add(Entity entity) {
        // ... (persist the entity)

        this.archiveService.createVersion(entity);
    }
}

这是一个好的做法，还是有任何缺点？到目前为止，我所看到的是服务依赖于存储库，而不是相反。

Answer 1

如果按照描述对其进行建模，您会使领域知识隐含并将其隐藏在存储库中，而存储库本身不是领域的一部分。我认为这不是一个好主意。

您可以使用 Domain Events 对其建模，即 EntityCreated。然后事件监听器可以获取事件并创建相应的存档条目。

更新以回答评论中提出的问题:

Conceptually, a Repository encapsulates the set of objects persisted in a data store and the operations performed over them, providing a more object-oriented view of the persistence layer. --Martin Fowler

除了正式定义:存储库知道如何存储和检索对象。为了能够实现这一点，它需要了解持久性机制或至少了解底层的数据访问层。

另一方面，域模型不应该依赖于外部的任何东西。在 Ports and Adapters 架构(比经典的分层方法更适合 DDD)存储库将是适配器之一。

您的域只知道其存储库的接口(interface)，实际的实现在外部。这样你就只有向内的依赖。基本上这是面向对象的，而具有向下指向、级联依赖关系的分层架构更像是一种过程方法。