我有点困惑.我在一家年轻的银行公司工作,我们决定实施DDD架构来打破复杂性.
所以,这是我的问题(它遵循团队中某人的设计建议).假设我们有3个不同的域名. D1,D2,D3,暴露域(网络)服务.每个域操作依赖于相同表的强类型业务实体.在这些域之前,我们希望微服务保证表中持久存储的数据是集中的. D1,D2和D3要求微服务保持符合特定规则的数据.我们希望微服务充当表的CRUD代理.微服务向D1,D2和D3域提供特定的DTO,将表混淆为D1,D3.
这种方法听起来不错吗？您是否会考虑在DDD架构中使用微服务来管理1个域的CRUD和数据一致性？使用微服务“CRUDing”和验证数据是否打破了有限的上下文？如果有的话,在DDD架构中处理微服务的最佳实践是什么？
非常感谢你的贡献,
[编辑]
微服务在单片系统无法维护的复杂情况下非常有用.它们不适合前期设计实施.另一方面,DDD试图在项目一开始就解决复杂问题.成功的DDD不应满足微服务实现.
解决方法
验证,计算和持久性(CRUD)之类的东西都是功能而不是服务.通过将这些任务集中到一个服务,您将所有其他服务紧密地耦合到它,并失去SOA的主要优势.让您的服务松散耦合,同时保持高凝聚力应该是您的首要目标.我觉得这个设计违反了这一点.
您希望将服务设计为相关业务功能的垂直切片,而不是集中式通用服务和层.服务应该包含从整个企业部署的数据库,从数据库一直到UI.此外,每个服务都应该拥有自己的数据库,或者至少是架构,如果不实用的话.只要您拥有共享数据库的服务,您就会再次紧密耦合.
最后一点,如果你的一个服务需要做一个简单的CRUD插入,那就应该是这样.无需先将其映射到域模型.将DDD保存为具有需要强制实际不变量的业务流程.它不一定是全有或全无的方法.使用对每个用例都有意义的工具.
