域驱动设计 – DDD – 第三方API接口应该在哪里？

如果我们考虑标准持久性存储库,解决方案很容易.我们将IStuffRepository放在Domain Layer中,将StuffRepositoryImplementation放在Infrastructure Layer中.

但是,当我们想要包装第三方API时,什么是好的模式？

我们可以应用相同的模式,在域层中具有IStuffGateway,在基础结构层中具有StuffGatewayImplementation.

但是这种方法存在问题.当我们考虑持久层时,我们可以控制我们持久存在的数据.但是当我们考虑第三方API时,我们无法控制,这意味着我们可以尝试拥有一定的接口签名,但它必须受到我们正在包装的内容的影响.因此,如果我们更改实现(将第三方替换为另一方),接口签名可能会更改,并且域将被更改.

另一种方法可能是将接口移到域外,并将其置于Infrasture层中,并实现它.这样,应用层就可以毫无问题地使用它(并保持域完整).但是这种方法从域中删除了重要的概念,从我的角度看这似乎很糟糕.

有关于此的任何参考意见吗？

解决方法

我始终保持我的Domain对象(Aggregates)纯净,没有副作用.这意味着我没有从域到任何其他层的任何依赖关系.持久性/存储库始终位于基础结构中. Application层使用它来持久化Aggregates.

当我使用CQRS时,我只保留我的写/命令端(Aggregates)纯. Readmodels依赖于特定实现并进行了优化.我使用了很多MongoDB进行持久化.

当我不使用CQRS时,我保持整个Aggregate没有依赖(我没有选择,分裂将是CQRS).

所以,在所有情况下,Domain都没有做任何IO,它没有副作用.这主要是因为我需要能够在并发更新的情况下安全地在Aggregate上重新执行命令.

但是,如果您决定使用接口,则应使用DIP：域拥有接口;这意味着域决定了方法的数量和签名.