这是构件化业务模型介绍的第三篇文章，前面的两篇文章为《构件化业务模型(1) – 框架》和《构件化业务模型(2) – 什么是业务构件》，有兴趣的朋友可以先读一读后再回来。

　　松耦合和高内聚

　　业务构件获得的好处源于两种相关但是截然不同的特征： 业务构件之间的松耦合提供了灵活性、适应性和灵敏度，同时，每一个业务构件内部的高内聚提供了高效率和更高的质量。

　　业务构件之间是松耦合的，而不是基于私有的或者定制的“硬”连接，业务构件之间有清晰定义的服务边界，在他们初始化、响应请求的时候形成、断开连接。松耦合同样依赖于一些互相都能理解的通讯语言，这样，异种系统之间也可以按照需要连接在一起。比如： 互联网银行可能允许通过电话亭和网络门户同时访问它的CallCenter功能。业务构件的这种特性让企业提供的服务具备更好的扩展性，同时，获得了更多的灵活性，保证企业可以获得为内部或者外部客户提供更多服务的潜在能力。与此相反，业务构件要求服务和服务的实现是分开的。事实上，从外部看一个业务构件，它就是一个黑盒子，它的内部运作是透明的。

　　在业务构件内部，业务构件将企业内部类似的业务服务聚合为一个简单的逻辑模块，提供了模块化和高效率。在这个意义上来说，构建一个业务构件最重要的就是将类似的业务放在一起。为了获得内聚性，业务构件内的每个服务都是唯一的，而且不会和其他构件内的服务重复。

　　把这些类似的业务放在一起有一个额外的好处，就是暴露真正的专家和那些做得不好的人之间执行服务时的差异。在整合业务过程中推荐专家级的实践，整合后的业务构件将有效提升对业务和客户的服务质量。实际上，这也是在企业内部共享最佳实践的一种很好的方式。

　　许多公司都努力去实现高内聚。当互联网作为一种服务交付渠道一出现，一些企业就建立直接的Web网站作为一条新的业务线，独立完成服务、交叉销售和市场活动。这种方式让企业给用户的体验式混乱和复杂的。一个通过网站看到的市场信息和产品和另一个走进卖场、或者通过CallCenter和企业交互的用户看到的东西不一样。这些公司没有实现在服务、销售和市场之间共享高内聚的活动，不考虑任何和渠道相关的因素。

　　更加聪明和优雅的方式是一次性的创建这种服务能力，然后再不同的渠道之间去共享它，只是针对不同的环境调整用户界面。这样，对待用户的方式、用户可选的服务和产品、对用户公布的市场信息都是一致的。不考虑这种跨越人、流程和技术的高内聚的活动让很多企业环境更加复杂。