当缺少功能集成时，持续集成可能就遥不可及了。尤其是在团队不具备相关的技术或者行政组织来维护持续集成，或者是某个团队又
大又笨拙的时候。所以这些界定的上下文可能要被良好地定义和multiple teams formed。协同工作于有紧密关系的应用程序上的不协


调团队有时会进展很快，但他们所做的有可能很难整合。他们在转换层和技巧花样上花费了过多的时间，而没有在最重要的持续集成上
下功夫，做了许多重复劳动也没有体味到通用语言带来的好处。

因此，需要指派两个团队同意共享的领域模型子集。当然除了模型的子集部分，还要包括代码自己或者和模型相关联的数据库设计子
集。这个明确被共享的东西有特别的状态，没有团队之间的沟通不能做修改。

要经常整合功能系统，但是可以不用像在团队里进行持续集成那么频繁。在集成的时候，在两个团队里都要运行测试。
共享内核的目的是减少重复，但是仍保持两个独立的上下文。对于共享内核的开发需要多加小心。两个开发团队都有可能修改内核代
码，还要必须整合所做的修改。如果团队用的是内核代码的副本，那么要尽可能早地融合（Merge）代码，至少每周一次。还应该使
用测试工具，这样每一个针对内核的修改都能快速地被测试。内核的任何改变都应该通知另一个团队，团队之间密切沟通，使大家都
能了解最新的功能。