这是我对自己造成的一个奇怪的问题。我们在工作中有一些关于如何实现实际上几乎是面向服务的体系结构（SOA）的争论，其中一些瑕疵是不值得进入的。也就是说，它是一堆简单的小服务（大多数情况下，传统包装器并不是那么少），它们将用于构建SaaS Web应用程序。
无论如何，辩论的一个问题是，是否使用无共享方法，并让每个服务通过该服务的API与其他服务进行通信，或者是否开发某种类型的共享API库，这些API将由各种服务导入直接相互沟通。后者可能会让人们想起CORBA。
所以，我对团队的建议是，对于每个感觉强烈的人 - 我们中的一些人 - 进行研究，并就我们个人想要实施该系统做出明确的案例。然后，希望减少确认偏见并启发每个人，为我们如何不亲自想要实施该系统做出一个很好的引用案例。然后我们都回到一起并散开它。
我的问题是，我发现除了CORBA示例之外，很难搜索紧密耦合，类似CORBA的import-a-library设计的想法。有没有这样做的支持者，特别是而不是解耦的SOA架构？或者只是这个时代的一般支持者？我赞成无共享架构，其中每个服务都有自己定义良好的API，现在我需要为我不赞成的内容做一个演示，但我甚至找不到任何支持证据或者不是来自SOA前时代的信息。
答案 0 :(得分：3)
与大多数“X vs Y”问题一样，答案是取决于。
脱钩不是灵丹妙药。虽然它有许多好处（可重用性，模块化，测试，更容易维护等......），但它可能导致解决方案的过度设计（因此可能需要更长的时间来创建并增加更多的进入/理解障碍）并且通常有一些对绩效的影响。为了它而避免脱钩/抽象也是好的（除非它很容易或“低悬的果实”）。否则，请确保您有一些不错的用例来支持它。
这很大程度上取决于您的项目类型，进度和性能目标。在考虑您的项目之前，不要问哪个 x 更好，而是更明智地询问如何以具体而有意义的方式将每个 x 应用于您的项目，并判断它基于此。