Architecture SOA中的循环依赖

我猜，这是一个常见的问题，但我将尝试描述我目前的问题

我有一个基本服务，让我们把它命名为“CoreService”，它提供了我想说的“主要”功能：在DB中处理数据（我们的应用程序中有一个集中的DB）。还有许多其他应用程序，其中一些应用程序有自己的用于本地目的的数据库。还有一个简单的“通知服务”。其目的是向不同的订户广播消息

通常，此NotificationService从“ExternalWorld”调用，并向不同的服务发送通知（其中包括“CoreService”）

今天，我看到了从“CoreService”调用“NotificationService”的必要性

我在这里担心的是，我引入了一个循环依赖关系：“NotificationService”需要知道如何向每个服务发送消息（包括“CoreService”，因此它需要知道“CoreService”接口，因此它需要引用“CoreService”），而“CoreService”需要向“NotificationService”发送消息（所以它也需要引用它）…循环依赖

问题：我们应该如何构建架构来处理此类问题

---

非常感谢！

当我写完问题后，我发现了一些想法：

在“NotificationService”中，我需要定义两个接口“IMessagesSender”和“IMessagesReceiver”

每个用户都应该实现“IMessagesReceiver”，其地址应该写入“NotificationService”的配置文件中

每个消息发送者都应该使用描述“IMessageSender”接口的“wsdl”文件，并且应该在自己的配置文件中使用NotificationService的“address”记录

在这种情况下，我们不会删除循环依赖项，但它似乎是一个解决方案

现在，我很难说什么是最好的方法，这个解决方案的优缺点是什么，所以请评论一下（和/或建议更好的方法）

---

非常感谢！

您必须从点对点切换到中介。中介现在将负责将源绑定到目标，并适当地路由/发布消息（ESB在我脑海中响起）

解释

您不直接从NotificationService引用CoreService，反之亦然。两者都将订阅他们感兴趣的主题。例如，CoreService将事件发布到NotificationService将订阅的主题（CoreService还将订阅NotificationService向其发布事件的主题）。然后由主题处理程序（消息传递系统或ESB等）负责将事件转发给给定主题的所有订户。这样，服务彼此松散耦合，甚至不需要知道它们的存在

---

目前，您正在使用NotificationService作为中介/ESB，因此如果您愿意，它将成为一个基础设施服务，因此会出现循环依赖关系等问题。它不再是一个业务服务。

NotificationService在这里是一个中介，不是吗？同意。我的“NotificationService”显然计划成为一个中介吗？p很可能我遗漏了什么？NotificationService应该具备什么样的特性才能成为调解人？谢谢我的意图是使用NotificationService作为主题处理程序。如果我正确理解了你的建议，请看这里（）好吗？