在两个团队都有兴趣合作时，客户-供应商关系是可行的。客户非常依赖于供应商，但供应商不是。如果有管理保证合作的执行，供应
商会给于客户需要的关注，并聆听客户的要求。如果管理没有清晰地界定在两个团队之间需要完成什么，或者管理很差，或者就没有
管理，供应商慢慢地会越来越关心它的模型和设计，而也越来越疏于帮助客户。毕竟他们有自己的工作完成底线。即使他们是好人，
愿意帮助其他团队，时间的压力却不允许他们这么做，客户团队深受其害。在团队属于不同公司的情况下，这样的事情也会发生。交
流是困难的，供应商的公司也许没兴趣在关系沟通上投资太多。他们要么提供少许帮助，或者直接拒绝合作。结果是客户团队孤立无
援，只能尽自己的努力摸索模型和设计。

当两个开发团队有客户-供应商关系，而且供应商团队没有动力为客户团队的需要提供帮助时，客户团队是无助的。利他精神也许会使
供应商开发者做出许诺，但是他们很有可能完不成。美丽的许诺导致客户团队根据那些从来都不会存在的功能制定计划。客户的项目
会被一直耽搁，知道团队最终学会如何协同工作。符合客户团队需要的接口不在卡片里。

客户团队没有多少选择。最常见的现象是将它从供应商那儿分割出来，自己完全独立。在后面的“分割方法”模式中我们在对它做详
细介绍。有时供应商子系统提供的好处不值得所付出的努力。创建一个分割的模型，以及在不考虑供应商模型的情况下做设计也许更
简单些。但并不总是管用。

有时在供应商模型里会有些数据，这时不得不维持一个连接。但是因为供应商团队不帮助客户团队，所以后者也不得不采取一些措施
保护自己，以防止前者对模型所做更改带来的影响。他们需要实现连接两边上下文的转换层。也有可能供应商团队的模型没有被很好
地理解，效用发挥不出来。虽然客户上下文仍然可以使用它，但是它应该通过使用一个我们后面要讨论的“防崩溃层”来保护自己。
如果客户不得不使用供应商团队的模型，而且这个模型做得很好，那么就需要顺从了。客户团队遵从供应商团队的模型，完全顺从
它。这和共享内核很类似，但有一个重要的不同之处。客户团队不
能对内核做更改。他们只能用它做自己模型的一部分，可以在所提供的现有代码上完成构建。在很多情况下，这种方案是可行的。当
有人提供一个丰富的组件，并提供了相应的接口时，我们就可以将
这个组件看作我们自己的东西构建我们的模型。如果组件有一个小的接口，那么最好只为它简单地创建一个适配器，在我们的模型和
组件模型之间做转换。这会隔离出我们的模型，可以有很高的自由度去开发它。