微服务是否打破了有界上下文？答案

【问题标题】：Do microservices break the bounded context?微服务是否打破了有界上下文？
【发布时间】：2015-06-20 15:03:13
【问题描述】：

我有点困惑。我在一家年轻的银行公司工作，我们决定实施 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 不应该满足微服务实现。

【问题讨论】：

不确定这是否能回答你所有的问题，但我发现这是一本关于微服务主题的有趣读物：particular.net/blog/microservices-future-or-empty-hype
你可以选择任何你想要的架构，没有像 DDD 架构这样的东西。由微服务组成的架构在使用 DDD 时也能正常工作（或不好）。
在 DDD 中，多个域不会共享相同的数据库表。这也适用于微服务。从您在问题中所写的内容来看，您的系统似乎根本不适合 DDD 方法。

标签： domain-driven-design microservices

【解决方案1】：

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

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

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

【讨论】：

【解决方案2】：

微服务不应该“破坏”限界上下文，它们是互补的，因为有一个natural correlation between microservice and BC boundaries。

我们想要一个微服务来保证表中持久化的数据是一致的，集中的方式

微服务不是为了外观的目的。它们都是关于去中心化，而不是中心化。它们是围绕业务能力组织的模块化单元。它们通常会充当您的限界上下文的网关，在域之前，而不是到域之后的持久存储的代理。

您似乎试图对您的问题应用错误的解决方案 - 使用微服务作为以数据为中心的单体的融合点，这违背了他们的全部目的。

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

【讨论】：

好点。我们微服务的目标是“保护”数据和表不被域应用程序滥用。不确定这是一个好方法。 DDD 应该与持久性无关。通过阻止其他域了解“受保护”数据，我们将无法向域提供特定于它们的信息。此外，我相信微服务将包含 CRUD 功能（它们对服务没有价值）和业务规则。没有业务流程。也许我们应该考虑像业务规则引擎这样的东西......
您要构建的服务似乎是您的域，因为它们包含业务规则。你想要一个简化的 DDD 应用程序和一个支持它的智能微服务，这真的……很奇怪。