domain-driven-design - 微服务是否打破了有界上下文？

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 的主要优势。使您的服务松散耦契约(Contract)时保持高内聚性应该是您的主要目标。我觉得这个设计违反了那个。

您希望将服务设计为相关业务功能的垂直切片，而不是使用集中的通用服务和层。服务应该由部署在整个企业中的组件组成，从数据库一直到 UI。此外，如果不切实际，每个服务都应该有自己的数据库或至少有架构。一旦您拥有共享数据库的服务，您就会再次变得紧密耦合。

最后要注意的是，如果您的一个服务需要执行简单的 CRUD 插入，那么这就是全部。无需先将其映射到域模型。为具有需要强制执行的实际不变量的业务流程保存 DDD。它不必是全有或全无的方法。使用对每个用例都有意义的工具。