在《松散耦合的七个级别：实施和服务契约》和《松散耦合的七个级别：服务策略和流程》中，我们介绍了松散耦合的实施、服务契约、服务策略和流程，下面我们将来介绍数据模型和基础设施。　　

　　松散耦合的数据模型

　　如果我们已经使用以上定义的所有松散耦合的等级，公司应该能使他们的服务实施、契约、策略和未破损的流程任意变化。然而，这不足以应付不断变化的业务需求。当基础数据模型改变了会发生什么呢？如果服务消费者和供应商需要有共同的认识，为了之前定义的紧密耦合进行一次会话。因此，机构需要进一步他们的松散耦合目标，在服务的消费者和供应商之间共享数据模型，能使他们动态的、多种多样的改变。

　　对一些人来说，这似乎是一个非常复杂的任务。计算机毕竟不是人，所以他们不能处理任何格式或者数据定义的变化。然而，在这里，并不是所以希望都不能完成。首先，服务不能真正的互操作，除非他们能够理解和处理常见的数据。这意味着，尽管在他们之间存在语义依存的关系（我们会在短期内解决），因此不需要在他们之前信赖结构数据。模型的关键是服务数据的互操作性。然而，当模型改变了会发生什么呢？一个关键的方法是与你服务元数据的管理相同的方法，来来解决信息和模型的管理。数据模型可以视为元数据形式和异常管理、转换、服务媒介和数据服务（在这里详细描述）的使用，是使用所有松散耦合的数据结构的关键。引入松散耦合实施数据层，在某种程序上，提供了不同的关注点，以至于最根本的基本数据改变与上面的业务服务隔离。

　　此外，公司需要使维护服务的元数据和维护数据模型的结果一致。为什么维护模型的人们不是架构团队的一部分呢？模型与服务契约是不同的。他们以编码的元数据形式表示业务需求。因此，我们经常告诫公司，把他们架构团队的数据和信息引入到企业架构中。这个简单的调整和建立元数据并能够改变管理的行为，允许松散耦合数据模型和结构。

　　松散耦合的基础设施

　　在我们解决松散耦合最后一个困难之前，值得注意的是，如果它依靠一个供应商实施的话，这些所有等级的松散耦合都无关紧要。很多次，我们与声称他们的系统是松散耦合的架构师交往，但是如果他们从企业服务总线（ESB）或服务的基础设施迁移他们的实施到另一个地方，那么就会违反耦合。怎样才能真正的说他们的实施在如此庞大的信赖性的情况下是松散耦合的呢？企业架构师不值得全信，要求他们的服务的基础设施是中立的。这意味着，在任何时候，公司可以改变他们的基础设施，而不必重新建立所胡服务的消费者和供应商。

　　许多厂商承诺这种可交替性，但很少提供。事实上，整个行业似乎迈向单一供应商的SOA平台，这将使许多SOA提议在这一层紧耦合。这个ZapFlash服务作为警告公司，想要实现高程度的松散耦合：保持你的实施基础设施的中立，你就会成功。否则，你的SOA提议只能使你的业务部分的灵活性。

　　在随后的文章中，我们会继续为您介绍松散耦合的七个级别中的其他内容。敬请关注。