如何从ddd中的另一个有界上下文中检索数据？

Question

最初，有一个应用程序在桌面中运行，但是将来该应用程序将在Web平台上运行。

应用程序中有一些有限的上下文，其中一些需要从另一个上下文中检索数据。在这种情况下，我不知道在这种情况下必须使用哪种方法。

我考虑过使用调解器模式，即绑定上下文“ A”请求数据“ X”，然后调解器调用另一个绑定上下文，例如B“”，并获取正确的数据“ X”。最后，中介器将数据“ X”带到BC“ A”。

当应用程序在Web上运行时，这种情况将有所改变，然后我想到使用微服务也使用meaditor模式从另一个微服务请求数据。

这两种方法都是有趣的还是还有更好的解决方案？

请问有人可以帮我吗？

非常感谢！

Answer 1

如果通过数据库或API调用从其他范围检索数据，则您的体系结构可能陷入死星模式，因为它给客户端上下文带来了不必要的耦合和知识。

一种更好的方法可能是将事件驱动的机制（例如webhook或消息队列）视为发出要共享的数据以订阅上下文的一种方式。这很好，因为它可以通过跨上下文的数据复制来减少有界上下文的耦合，从而导致有界上下文的独立性更高。

这给您的感觉是“谁在乎边界上下文B是否不可用ATM，边界上下文A和C在它们内部有它们需要的数据，由于与数据更新相关的事件记录在队列中，因此我可以稍后继续同步”

Answer 2

您需要的是用于集成的ddd模式。 BC“ B”在上游，“ A”在下游。您可以在上游使用OHS PL，在下游使用ACL。实际上，这是上游的REST API和下游的适配器。每当A需要B的数据时，适配器都会调用REST API并将返回的信息调整为A域模型。这将是同步的。如果您想进行异步集成，则B会将事件与信息一起发布到MQ，而A会监听这些事件并获取信息。

Answer 3

该问题的答案分为两个不同的区域：

在不同上下文之间进行通信的
• 逻辑挑战，其中相同数据可能以非常不同的方式使用。一个上下文如何解释数据的含义？
• 和在独立系统之间同步数据的技术挑战。当它们都具有“相同”数据的独立副本时，我们如何保证每个系统行为的正确性？

从逻辑上讲，上下文映射用于定义需要以任何方式进行通信（共享数据）的任何有界上下文之间的关系。控制数据的域模型仅适用于单个有界上下文，因此需要某种方法来解释来自另一个上下文的数据。这就是埃文（Evan）书中的模式发挥作用的地方：客户/供应商，遵从者，已发布的语言，开放主机，反腐败层或（保护模式）单独的方式。

在服务之间使用中介器可以作为anti-corruption layer pattern的实现：服务不需要说同一种语言，因为它们之间有一个独立的缓冲区译文。在微服务架构中，这可能是两种截然不同的上下文之间的某种集成服务。

从技术角度来看，在不同范围的上下文中服务之间的直接API调用会引入这些服务之间的依赖关系，因此首选事件驱动的方法（如Allan提到的方法），前提是您的应用程序对此具有一定的影响（最终一致性数据）。选择一个消息传递平台为您提供必要的保证，使数据保持同步非常重要。大多数异步消息传递协议都保证“至少一次”传递，但是消息的顺序和重复项的重复数据删除取决于应用程序。

有时候使用同步API调用会更简单，尤其是当您发现自己进行大量请求/响应类型的消息传递时（如果您的服务相互之间发送命令类型的消息，则可能会发生这种情况）。

复合UI是另一种模式，通过让每个组件从相关服务中提取数据，然后在UI本身中共享/组合数据，您可以在表示层中进行数据集成。这比后端杂乱的跨服务API调用网络更易于管理，特别是如果您使用IT / Ops服务，NGINX或MuleSoft的Experience API之类的方法来实现“前端后端”。

Answer 4

我想在DDD中添加有关分析的注释。存在几种将数据发送到分析的方法。 1）如果您有大型企业应用程序，则应该从所有有界上下文中收集大量统计信息，更好地将分析移到单独的服务中，并使用消息队列在那里发送数据。 2）如果您有一个简单的应用程序，则在其他情况下将Analytic与您的App分开，并使用事件或命令与之对话。