如果我们考虑标准持久性存储库,解决方案很容易.我们将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：域拥有接口;这意味着域决定了方法的数量和签名.
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。