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

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

所以，这里是我的问题（它遵循团队中某个人提出的设计建议）。假设我们有3个不同的域。D1、D2、D3，它们公开域（web）服务。每个域操作依赖于相同表的强类型业务实体。在这些域之前，我们需要一个微服务来保证表中持久化的数据以集中的方式保持一致。D1、D2和D3要求微服务保存符合特定规则的数据。我们希望微服务充当表的CRUD代理。微服务向D1、D2和D3域提供特定的DTO，将表混淆到D1、D2和D3

这个方法听起来好吗？您会考虑使用DDD体系结构中的微服务来管理1个域的CRUD和数据一致性吗？使用微服务“CRUDing”和验证数据是否会破坏有界上下文？在DDD体系结构中处理微服务的最佳实践是什么（如果有的话）

非常感谢你的贡献

[编辑]

以下文章帮助我完善了我的想法：

---

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

验证、计算和持久性（CRUD）等都是功能，而不是服务。通过将这些任务集中到一个服务，您将所有其他服务紧密耦合到该服务，从而失去了SOA的主要好处。让您的服务松散耦合，同时保持高内聚性应该是您的主要目标。我觉得这个设计违背了这一点

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

---

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

微服务不应该“打破”有界上下文，它们是互补的，因为存在一个

我们需要一个微服务来保证表中持久化的数据是安全的 一致的，集中的

这里的微服务不是用于facading目的的。它们都是关于分散，而不是集中。它们是围绕业务能力组织的模块化单元。它们通常充当域前面的有界上下文的网关，而不是域后面持久存储的代理

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

---

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

不确定这是否回答了您的所有问题，但我发现这是一本关于微服务主题的有趣读物：您可以选择您想要的任何体系结构，没有DDD体系结构。由微服务组成的体系结构在使用DDD时也能正常工作（或不正常工作）。在DDD中，多个域不会共享相同的数据库表。微服务也是如此。从您在问题中所写的内容来看，您的系统似乎根本不适合DDD方法。这一点很好。我们微服务的目标是“保护”数据和表不被域应用程序滥用。我不确定这是一个好方法。DDD被认为是持久性不可知论的。通过阻止其他域了解“受保护”的数据，我们将无法向域提供特定于它们的内容。此外，我相信微服务将包含CRUD功能（它们对服务没有价值）和业务规则。没有业务流程。也许我们应该考虑一个类似业务规则引擎的东西……看来，您想要构建的服务是您的域，因为它们包含业务规则。你想有一个简单的DDD应用程序和一个智能微服务支持它，这真的是。。。奇怪的