微服务是否打破了有限的背景？

Question

我有点困惑.我在一家年轻的银行公司工作,我们决定实施DDD架构来打破复杂性.

所以,这是我的问题(它遵循团队中某人的设计建议).假设我们有3个不同的域名.D1,D2,D3,暴露域(网络)服务.每个域操作依赖于相同表的强类型业务实体.在这些域之前,我们希望微服务保证表中持久存储的数据是集中的.D1,D2和D3要求微服务保持符合特定规则的数据.我们希望微服务充当表的CRUD代理.微服务为D1,D2和D3域提供特定的DTO,将表混淆为D1,D2,D3.

这种方法听起来不错吗？您是否会考虑在DDD架构中使用微服务来管理1+域的CRUD和数据一致性？使用微服务"CRUDing"和验证数据是否打破了有限的上下文？如果有的话,在DDD架构中处理微服务的最佳实践是什么？

非常感谢您的贡献,

[编辑]

以下文章帮助我改进了我的想法:http://martinfowler.com/bliki/MicroservicePremium.html

微服务在单片系统无法维护的复杂情况下非常有用.它们不适合前期设计实施.另一方面,DDD试图在项目一开始就解决复杂问题.成功的DDD不应该满足微服务实现.

Answer 1

验证,计算和持久性(CRUD)之类的东西都是功能而不是服务.通过将这些任务集中到一个服务,您将所有其他服务紧密地耦合到它,并失去SOA的主要优势.让您的服务松散耦合,同时保持高凝聚力应该是您的首要目标.我觉得这个设计违反了这一点.

您希望将服务设计为相关业务功能的垂直切片,而不是集中式通用服务和层.服务应该包含从整个企业部署的数据库,从数据库一直到UI.此外,每个服务都应该拥有自己的数据库,或者至少是架构,如果不实用的话.只要您拥有共享数据库的服务,您就会再次紧密耦合.

最后,如果你的一个服务需要做一个简单的CRUD插入,那就应该是这样.无需先将其映射到域模型.将DDD保存为具有需要强制实际不变量的业务流程.它不一定是全有或全无的方法.使用对每个用例都有意义的工具.

Answer 2

微服务不应该"打破"有界上下文,它们是互补的,因为微服务和BC边界之间存在自然关联.

我们希望微服务能够保证表中持久存储的数据是集中的

微服务不是用于说明目的.而且他们都对去集中,而不是集中.它们是围绕业务能力组织的模块化单元.它们通常在域之前充当绑定上下文的网关,而不是域后面的持久存储的代理.

看起来你正在尝试将错误的解决方案应用于你的问题 - 使用微服务作为以数据为中心的整体的融合点,这会破坏它们的整个目的.

也许你应该详细说明你所说的"保证数据是否一致"和"保持数据符合特定规则".它可能只是在持久层或非微服务的服务中实现.