一旦界定的上下文被定义，我们就必须保持它的完整性。但多人工作于同一个界定的上下文时，模型很容易被分解。团队越大，问题
越大，不过通常只有三四个人会遇到严重的问题。但是，系统被破坏成更小的上下文后，基本上也就失去了完整性和一致性的价值。
就是一个团队工作于一个界定的上下文，也有犯错误的空间。

在团队内部我们需要充分的沟通，以确保每个人都能理解模型中每个部分所扮演的角色。如果一个人不理解对象间的关系，他就可能会
以和原意完全相反的方式修改代码。如果我们不能百分之百地专注于模型的纯洁性，就会很容易犯这种错误。团队的某个成员可能会在
不知道已经有自己所需代码的情况下增加重复代码，或者担心破坏现有的功能而不改变已有的代码选择重复增加。

模型不是一开始就被完全定义。先被创建，然后基于对领域新的发现和来自开发过程的反馈等再继续完善。这意味着新的概念会进入
模型，新的部分也会被增加到代码中。所有的这些需求都会被集成进一个统一的模型，进而用代码实现之。这也就是为什么持续集成
在界定的上下文中如此必要的原因。我们需要这样一个集成的过程，以确保所有新增的部分和模型原有的部分配合得很好，在代码
中也被正确地实现。我们需要有个过程来合并代码。合并得越早越好。对小的独立团队，推荐每日合并。我们还需要适当地采用构建
流程。合并的代码需要自动地被构建，以被测试。另外一个必须的邀请是执行自动测试。如果团队有测试工具，并创建了测试集，那
么测试就可以运行在每个构建上，任何错误都可以被检查出来。而这时也可以较容易地修改代码以修正报告的错误，因为它们被发现的
很早，合并、构建、和测试流程才刚开始。

持续集成是基于模型中概念的集成，然后再通过测试实现。任何不完整的模型在实现过程中都会被检测出来。持续集成应用于界定的
上下文，不会被用来处理相邻上下文之间的关系。