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