为了使 OO 系统尽可能地解耦，我正在考虑以下方法：
1）我们运行一个 RMI/目录之类的服务，对象可以在其中注册和发现彼此。他们通过接口与该服务对话
2）我们运行一个消息服务，对象可以向其发布消息，并注册订阅回调。同样，这通过接口发生
3）当对象A要调用对象B的方法时，通过上面的#1发现目标对象的唯一标识，并在消息服务上为对象B发布消息
4) 消息服务调用 B 的回调来给它消息
5) B 处理请求并在消息服务上发送对 A 的响应
6) A 的回调被调用并得到响应。
我觉得这个系统尽可能地解耦，但它存在以下问题：
1) 通信通常是异步的
2）因此它不是实时的
3）整个系统效率较低。
是否还有其他实际问题明显不适用于这种设计？你对这个设计有什么看法？
图书
企业集成模式
看来他正在谈论使用面向消息的中间件
这里有一些要考虑的事情
安全
什么会阻止另一个流氓服务注册为系统中的关键组件。您将需要验证和验证服务是他们所说的身份的方法。这可以通过 PKI 系统来完成。如果您的系统完全托管在 Intranet 上，则在某些情况下您可能不需要这样做。如果是这样的话，社会工程和流氓员工将是你最大的威胁。
合同
您的客户将与服务签订什么样的合同？消息会全部序列化为 XML 并作为 TextMessage 发送吗？如果您使用纯字节消息，如果您的服务要在多个平台上运行，则必须注意字节顺序。
同步
大多数开发人员无法正确理解和使用异步消息。在可能的情况下，创建一种调用“同步”消息的方法可能符合您的设计的最佳利益。我过去通过创建带有超时和返回对象的 sendMessageAndWait() 方法来完成此操作。在该方法中，您可以创建一个临时主题 id 来接收响应，为其注册一个侦听器，然后使用锁来等待您的临时主题返回消息。
不请自来的消息
如果您想允许您的服务向您的客户发送未经请求的消息，会发生什么？服务 A 中发生了一个关键事件，它必须通知您的客户或可能是 Watch Dog 服务。允许您的设计注册一个公共通信渠道，以便服务与客户进行通信，而无需客户发起对话。
故障转移
如果处理您的信用卡的关键服务出现故障怎么办？您需要实施故障转移和看门狗服务，以确保您的关键基础设施始终正常运行。您可以在注册表中注册服务列表，然后您的注册表可以提供主要服务，如果您的主要服务停止通信，则回退到辅助服务。或者，如果您的面向消息的中间件可以处理循环消息，您也许可以注册同一主题的所有服务。考虑创建一种方法来了解服务何时终止。由于大多数消息都是异步的，因此很难确定服务何时下线。这可以通过心跳和看门狗来完成。
我过去曾为需要通信的大型系统创建过几次此类系统。如果您和其他开发人员了解这种系统的优缺点，它会非常强大和灵活。
我能给出的最大建议是为您的其他开发人员构建一个工具包，这样他们就不必考虑如何注册服务、实现故障转移或响应来自客户端的消息。这些东西会杀死你的系统并让其他人说它太复杂了。让他们感到轻松，将允许您的系统以您需要的方式工作，具有灵活性和解耦性，同时不会给您的开发人员带来理解企业设计模式的负担。
这不是象牙塔建筑师/建筑。如果他说，“这就是它的方式，现在去做，不要打扰我，因为我知道我是对的。” 如果你真的想引用一个反模式，它可能是 Kitchen Sink。不，现在我想起来，它也不是厨房水槽。
如果你能找到一个，请将其作为评论发布。 反模式
耦合只是效率和可重用性之间的平衡。如果您希望系统的模块尽可能地可重用，那么这无疑是有代价的。
我个人认为最好定义一些可能会加强耦合但会提高效率的关键假设。
有些设计模式永远不会出现，只是因为它们提供的好处不值得付出复杂性的代价。
最简单的事情是什么？模块化成合理大小的例程，但要避免接口、服务、消息和所有这些，除非您将有多个实现或多个硬件资源来划分工作。
让它变得简单，然后重构那些被证明很重要的部分。