我们经常会遇到两个子系统之间关系特殊的时候：一个严重依赖另一个。两个子系统所在的上下文是不同的，而且一个系统的处理结
果被输入到另外一个。它们没有共享的内核，因为从概念上理解也许不可以有这样一个内核，或者对两个子系统而言要共享代码在技
术上也不可能实现。

让我们回到先前的例子。我们曾讨论了一个关于在线商店应用的模型，包括报表和通讯两部分内容。我们已经解释说最好要为所有的
那些上下文创建各自分开的模型，因为只有一个模型时会在开发过程中遇到瓶颈和资源的争夺。假设我们同意有分开的模型，那么在
Web 商店字系统和报表系统间的关系是什么样子的呢？共享内核看上去不是好的选择。子系统很可能会用不同的技术被实现。一个是
纯浏览器体验，而另一个可能是丰富的GUI 应用。尽管如果报表应用是用Web 接口实现，各自模型的注意概念也是不同的。也许会有
越界的情况，但还不足以应用共享内核。所以我们选择走不同的道
路。另外，E 商店子系统并不全依赖报表系统。E 商店应用的用户是Web 客户，是那些浏览商品并下单的人。所有的客户、商品和订
单数据被放在一个数据库里。就是这样。E 商店应用不会真的关心各自的数据发生了什么。而同时，报表应用非常关心和需要由E 商
店应用保存的数据。它还需要一些额外的信息以执行它提供的报表服务。客户可能在购物篮里放了一些商品，但在结账的时候又去掉
了。某个客户访问的链接可能多于其他人等。这样的信息对E 商店应用没有什么意义，但是对报表应用却意义非凡。由此，供应商子
系统不得不实现一些客户子系统会用到的规范。这是联系两个子系统的纽带。

另外一个和所用到的数据库相关联的需求是它的Schema。两个应用将使用同一个数据库。如果E 商店应用是唯一访问数据库的应
用，那么数据库Schema 可以在任何时间被改变以反应它的需要。但是报表子系统也需要访问数据库，所以它需要一些Schema 的稳
定性。在开发过程中，数据库Schema 一点也不能改变的情况是不可想像的。对E 商店应用这不代表是个问题，但对报表应用这肯定
是一个问题。这两个团队需要沟通，可能还需要在同一个数据库下工作，然后决定什么时候执行变更。对报表子系统来说这会是一个
限制，因为团队会倾向于随着开发的进展快速地变更和进展，而不是在E 商店应用上等待。如果E 商店应用团队有否决权，他们也许
会对要在数据库上做的变更强制加上限定，从而伤害到报表团队的行为。如果E 商店团队能独立行动，他们就会迟早破坏约定，然后
做一些报表团队还没有准备好的变更。但这个模式在团队处于统一管理的情况下有效，它会使决策过程变得容易，也能够产生默契。
当我们面对这样一个场景时，应该就开始“演出”了。报表团队应该扮演客户角色，而E 商店团队应该扮演供应商角色。两个团队应
该定期碰面或者提邀请，像一个客户对待他的供应商那样交谈。客户团队应该代表系统的需求，而供应商团队据此设置计划。当客户
团队所有的需求都被激发出来后，供应商团队就可以决定实现它们的时间表。如果认为一些需求非常重要，那么应该先实现它们，延
迟其他的需求。客户团队还需要输入和能被供应商团队分享的知识。这个过程Flows one way，但是有时是必要的。

两个子系统之间的接口需要预先明确定义。另外还要创建一个统一的测试集，在任何接口需求被提出的时候用于测试。供应商团队可
以在他们的设计上大胆地工作，因为接口测试集的保护网会在任何有问题的时候报警。

在两个团队之间确定一个明显的客户/供应商关系。在计划场景里，让客户团队扮演和供应商团队打交道的客户角色。为客户需求做充
分的解释和任务规划，让每个人理解相关的约定和日程表。联合开发可以验证期望（Expected）接口的自动化验收测试。将这
些测试增加到供应商团队的测试集里，作为它的持续集成的一部分运行。这个测试能使供应商团队放心地做修改，而不用担心影响客
户团队的应用。