原文地址：http://www.theserverside.com/news/1375715/Services-and-the-real-meaning-of-coupling
当一个客户向你要求一些新功能的时候会发生什么？你是否必须在四个不同的系统进行改变，隔离地测试每个部分再合并，并使用独立的测试，设施和操作团队？
如果是这样，你得架构很可能不是面向服务的（SOA）。在这个帖子中，我将研究耦合的真正意义，以及其如何与SOA关联起来。
我将像其他讲述SOA的人那样，在这个帖子中努力定义我对SOA的理解。我将通过讲述“SOA不是什么”来实现这点。
面向组件设计（CBD）：
首先SOA与面向组件设计不同。SOA架构中的服务是分布的。面向组件中的组件是在每个系统自身程序包中的一组代码（2进制文件）。从这点看，EJB既是一个服务又是一个组件。
基于组件的复用通常比基于服务的复用简单。在基于服务的复用中，改变复用组件带来的冲击是非常容易处理的。可能存在我自己没有意识到的系统使用了我的服务的情况。在组件中，也存在这个问题，但是（面向服务）每一个系统必须意识到需要更新这个组件，所以任何系统中偶然的破坏都会导致另外系统的更改。
面向商业：
不仅仅是分布式这点，我觉得SOA服务想要成为面向商业的。这就意味着改变一个服务的原因往往是服务的商业需求发生变化。特别地，如果一个服务的变化是由另一个服务中的新的商业需求所引起的，我就要面对损失。
耦合：
“耦合”的真正意义是：如果改变一个系统非常可能需要改变另外一个系统，那么说这两个系统紧密耦合。这是一个很难通过观察代码而衡量的尺度，然而很多人还是认为衡量代码能够帮助理解耦合。
非SOA分布式的真正硬伤是：不清晰的耦合。如果我让系统中不同的两部分远程分布，它们则是部署时间解耦。但是如果我必须同时更新两部分，这种耦合带来的伤害比带来的帮助更大。如果我在两部分之间以String作为传输数据类型，这样“我们能支持未来任何关于XML schema的改变”，这些部分部署时间解耦。但是如果我必须同时更新每一部分，这样的解耦带来伤害而没有提供任何帮助。理由是耦合依然存在，只是不清晰了。我喜欢将这个方法称作“用代码度量射你自己的脚”。
如果我的服务网络设计的良好，我得服务应该是低耦合的：改变一个服务很可能不会影响其他的服务。然而，完成这样的目标是很困难的。如果我使用了错误的方式，他将伤害到我。
结论：
如果你能识别和抽取真正松耦合的服务，SOA对你来说将非常合适。由于组成部分紧密耦合，你仍然能够从复用中得到好处，但是你最好还是用面向组件设计的方法。（不能完全掌握SOA，SOA只能成为杀手）
