寻找紧密耦合设计与SOA的支持者

Question

这是我自己造成的一个奇怪的问题。我们正在进行一场关于如何实现实际上几乎是面向服务的体系结构（Service-Oriented Architecture，SOA）的辩论，并带有一些不值得进入的瑕疵。也就是说，这是一些简单的服务（主要是传统包装不是很少），将用于构建SaaS Web应用程序。

无论如何，辩论的问题之一是是否使用无共享方法，并让每个服务通过该服务的API与其他服务进行通信，或者是否开发某种类型的共享API库，以便通过各种服务直接相互沟通。后者可能会提醒人们CORBA。

所以，我对这个团队的建议是，对于那些强烈感受的人 - 我们中的一些人 - 去研究并为我们个人如何实现系统做一个引用良好的案例。那么，为了希望减少确认偏差并启发每个人，请为我们如何不亲自实施该系统提供一个引用良好的案例。然后，我们都会回到一起并将其散列出来。

我的问题是，我发现紧密耦合的CORBA类导入库设计非常难以搜索，除了CORBA示例之外。是否有支持者这样做，特别是而不是是一个分离的SOA架构？或者只是这个时代这个想法的一般支持者？我赞成无共享的架构，每个服务都有自己定义好的API，现在我需要为我不赞成的做一个演示，但即使找到任何支持证据，我也遇到了麻烦或者不是来自SOA之前时代的信息。

Answer 1

像大多数“X对Y”的问题一样，答案是它取决于。

解耦不是一颗银子弹。虽然它有很多好处（可重用性，模块化，测试，更容易维护等），但它可能会导致解决方案的过度设计（因此可能需要更长的时间来创建和添加更多的入口/理解障碍），并且通常有一些对性能的影响。避免为了它而去耦/抽象也是很好的（除非它很容易或“低挂的果实”）。否则，请确保您有一些体面的用例来支持它。

很多这取决于您的项目类型，时间表和性能目标。不要问在考虑项目之前哪个项目更好，哪个项目可以以具体和有意义的方式应用到项目中，然后根据它来判断。