微服务会破坏有界上下文吗？
Do microservices break the bounded context?
我有点困惑。我在一家年轻的银行公司工作，我们决定实施 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 不应该满足微服务实现。
诸如验证、计算和持久化 (CRUD) 之类的东西都是功能，而不是服务。通过将这些任务集中到一项服务，您将所有其他服务紧密地耦合到它，并且失去了 SOA 的主要优势。使您的服务松耦合同时保持高内聚应该是您的主要目标。我觉得这个设计违反了那个。
您想将服务设计为相关业务功能的垂直切片，而不是集中式通用服务和层。服务应该由部署在整个企业中的组件组成，从数据库一直到 UI。此外，每个服务都应该有自己的数据库，如果不可行，至少应该有模式。一旦您有共享数据库的服务，您就会再次紧密耦合。
最后一点，如果您的一项服务需要执行简单的 CRUD 插入，那么就应该如此。无需先将其映射到域模型。为具有需要强制执行的实际不变量的业务流程保存 DDD。它不一定是全有或全无的方法。使用对每个用例有意义的工具。
微服务不应该 "break" 限界上下文，它们是互补的，因为有 natural correlation between microservice and BC boundaries.
we want a microservice to garantee that data persisted in tables is
consistent, in a centralized manner
这里的微服务不是为了装饰目的。它们都是关于 de 中心化，而不是中心化。它们是围绕业务能力组织的模块化单元。它们通常充当通往您的限界上下文的网关，在域之前，而不是持久存储在域之后的代理。
您似乎正试图对您的问题应用错误的解决方案——使用微服务作为以数据为中心的单体的聚合点，这违背了它们的全部目的。
也许您应该详细说明 "guarantee data persisted is consistent" 和 "persist data conforming to specific rules" 是什么意思。它可能只是在持久层或非微服务的服务中实现。
我有点困惑。我在一家年轻的银行公司工作，我们决定实施 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 不应该满足微服务实现。
诸如验证、计算和持久化 (CRUD) 之类的东西都是功能，而不是服务。通过将这些任务集中到一项服务，您将所有其他服务紧密地耦合到它，并且失去了 SOA 的主要优势。使您的服务松耦合同时保持高内聚应该是您的主要目标。我觉得这个设计违反了那个。
您想将服务设计为相关业务功能的垂直切片，而不是集中式通用服务和层。服务应该由部署在整个企业中的组件组成，从数据库一直到 UI。此外，每个服务都应该有自己的数据库，如果不可行，至少应该有模式。一旦您有共享数据库的服务，您就会再次紧密耦合。
最后一点，如果您的一项服务需要执行简单的 CRUD 插入，那么就应该如此。无需先将其映射到域模型。为具有需要强制执行的实际不变量的业务流程保存 DDD。它不一定是全有或全无的方法。使用对每个用例有意义的工具。
微服务不应该 "break" 限界上下文，它们是互补的，因为有 natural correlation between microservice and BC boundaries.
we want a microservice to garantee that data persisted in tables is consistent, in a centralized manner
这里的微服务不是为了装饰目的。它们都是关于 de 中心化，而不是中心化。它们是围绕业务能力组织的模块化单元。它们通常充当通往您的限界上下文的网关，在域之前，而不是持久存储在域之后的代理。
您似乎正试图对您的问题应用错误的解决方案——使用微服务作为以数据为中心的单体的聚合点，这违背了它们的全部目的。
也许您应该详细说明 "guarantee data persisted is consistent" 和 "persist data conforming to specific rules" 是什么意思。它可能只是在持久层或非微服务的服务中实现。