域驱动设计 – DDD – 第三方API接口应该在哪里？
发布时间：2020-12-14 04:54:33 所属栏目：百科 来源：网络整理
导读：如果我们考虑标准持久性存储库,解决方案很容易.我们将IStuffRepository放在Domain Layer中,将StuffRepositoryImplementation放在Infrastructure Layer中. 但是,当我们想要包装第三方API时,什么是好的模式？ 我们可以应用相同的模式,在域层中具有IStuffGatewa
|
如果我们考虑标准持久性存储库,解决方案很容易.我们将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：域拥有接口;这意味着域决定了方法的数量和签名. （编辑：李大同） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |