微服务是否会中断边界上下文？

Question

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

所以，这是我的问题（它遵循团队中某人提出的设计建议）。假设我们有 3 个不同的域。D1、D2、D3，公开域 （Web） 服务。每个域都操作依赖于相同表的强类型业务实体。在这些域之前，我们希望微服务以集中方式保证持久保存在表中的数据是一致的。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

微服务不应该“打破”边界上下文，它们是互补的，因为微服务和 BC 边界之间存在自然相关性。

我们希望微服务以集中的方式保证持久化在表中的数据是一致的

微服务不是为了外观目的。它们都是关于权力下放，而不是集中化。它们是围绕业务功能组织的模块化单元。它们通常充当域前面的界定上下文的网关，而不是域后面持久存储的代理。

似乎您正在尝试将错误的解决方案应用于您的问题 - 使用微服务作为以数据为中心的单体的融合点，这违背了他们的整个目的。

也许您应该详细说明“保证持久化的数据是一致的”和“持久化符合特定规则的数据”的含义。它可能只是在持久性层或非微服务的服务中实现。

Answer 2

诸如验证、计算和持久性 （CRUD） 之类的东西都是函数，而不是服务。通过将这些任务集中到一个服务中，您将所有其他服务与该服务紧密耦合，并失去 SOA 的主要优势。在保持高凝聚力的同时使服务松散耦合应该是您的主要目标。我觉得这个设计违反了这一点。

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

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