域服务可以访问存储库吗?

mgr*_*zko 14 domain-driven-design

域服务可以访问存储库吗?或者他们应该处理由Application Services传递给它们的聚合/实体?

考虑相同业务操作的两个代码示例 - 汇款.作为第一步,我改变账户余额.然后我获取通知电子邮件并发送通知.我知道,我应该抽象通知的发送方式(电子邮件,短信,信鸽),但为了简单起见,我们假设我们现在只支持电子邮件.

变体1使用域服务中的存储库.变体2解决了应用程序服务中的依赖关系并将它们传递给TransferDomainService.

在此示例中,操作很简单(从一个帐户中减去钱并将其添加到另一个帐户).但是如果涉及更多业务规则(可能需要访问更多聚合)?如果应用了变体2,那么应用程序服务必须知道域服务究竟需要什么.如果选择了变量1,则域服务会向存储库询问执行其任务所需的内容.

(关于代码片段的注释:用于删除Java冗余的Groovy代码.名称中包含DDD构建块)

变式1

class TransferApplicationService {
    def transferDomainService
    def customerDomainService
    def emailNotifierInfrastructureService

    def transfer(fromAccount, toAccount, amount) {
        transferDomainService.transfer(fromAccount, toAccount, amount)
        def email = customerDomainService.accountNotificationEmail(toAccount)
        emailNotifierInfrastructureService.notifyAboutTransfer(email, amount)
    }
}

class TransferDomainService {
    def accountRepository
    def transfer(fromAccount, toAccount, amount) {
        def from = accountRepository.findByNumber(fromAccount)
        def to = accountRepository.findByNumber(toAccount)
        to.decreaseBalance(amount)
        from.increaseBalance(amount)
    }
}
Run Code Online (Sandbox Code Playgroud)

变体2

class TransferApplicationService {
    def accountRepository
    def transferDomainService
    def customerDomainService
    def notifierInfrastructureService

    def transfer(fromAccount, toAccount, amount) {
        def from = accountRepository.findByNumber(fromAccount)
        def to = accountRepository.findByNumber(toAccount)
        transferDomainService.transfer(from, to, amount)
        def email = customerDomainService.accountNotificationEmail(toAccount)
        notifierInfrastructureService.notifyAboutTransfer(email, amount)
    }
}

class TransferDomainService {
    def transfer(fromAccount, toAccount, amount) {
        to.decreaseBalance(amount)
        from.increaseBalance(amount)
    }
}
Run Code Online (Sandbox Code Playgroud)

pla*_*alx 11

好吧,我想说如果选择加载哪些实体归结为大量的域逻辑,那么我可以将该任务委托给域服务.但是,我通常会努力解决应用程序服务中的聚合根引用.

但是,我认为您可能还有其他一些问题,或者至少您可以使用其他一些DDD战术模式(如Domain Events)来改进您的设计.

在我看来,您根本不应该在应用程序服务中发送任何通知代码.相反,域服务可以引发MoneyTransferred域事件.然后,您将拥有此活动的订阅者,该订阅者将负责发送电子邮件.

除了解耦组件之外,您还在丰富域中无处不在的语言.现在发送通知是为了响应正在进行的汇款而不是作为同一过程的一部分,并且许多其他感兴趣的各方也可以做出反应.

最后,您的域服务当前违反了每个事务只修改一个聚合根的规则.我不是说你永远不会破坏规则,但通常这是一个很好的指标,你应该使用最终的一致性,或者你的聚合边界是错误的.

如果你考虑一下,账户之间的资金转移很少以原子方式发生(如果他们这样做的话).我想如果这两个账户在同一个银行中就可能出现这种情况,但是当转账跨越多个银行时,必须使用最终的一致性.

  • 没有这样的"规则",一个服务只能修改一个AR. (2认同)
  • 我现在想不出一个例子,但它不应该是一个人为的规则.这一切都取决于域和业务流程_might_涉及超过1个AR.聚合定义了一致性边界,但域服务(用例)可能需要处理多个聚合,即多个不同的事务.我不知道我是否有多大意义,DDD充满了非常微妙和棘手的麻木 (2认同)