当有多个团队时，我们必须面对一系列不同的挑战，开发这样一下项目的认为需要不同的管理和协作。企业级项目通常都是大型项目
需要使用许多的技术和资源。这样的项目的设计将仍然基于一个领域模型展开，并且我们需要采用适当的measure 来确保项目成功。

当多个团队开发一个项目时，代码开发是并行的，每个团队都会被指派模型的一个特定部分。那些部分不是独立的，多少都有些关联
性。它们都是从一个大的模型出发，然后实现其中的一部分。

我们可以这样说，其中的一个团队创建了一个模块，然后提供给其他的团队使用。某个团队的开发人员开始在自己的模块中使用这个模块，
但发现还缺少一些功能，于是他增加了这个功能并放到代码库里面，以便所有的人都能使用。但是他也许没有意识到，这其实是对模型的一
个变更，这个变更很有可能破坏系统的功能。这种情况很容易发生，因为没有人会花时间去完全理解整个模型。每个人都知道自己的后院
里有什么，但对其他地方则并不是非常了解。好的开始未必就是成功的一半。

比较常见的情况是，很多开始良好的模型和流程到最后都一塌糊涂。模型的首要需求是一致性，条款统一和没有矛盾。模型的内部一致被称
为“统一”。一个企业项目应该有一个模型，涵盖企业的整个领域，没有矛盾和重叠的条款。统一的企业模型是不容易实现的理想状态，有时
甚至都不值得尝试。这些项目需要许多团队的通力协作。在开发流程中，团队需要高度的独立性，因为他们没有时间去经常开会和讨论设计。
要调和这些团队是很有挑战性的。也许他们属于不同的部门，有着不相干的管理。当模型的设计开始部分独立时，我们就开始面临失去模型
完整性的可能性。试图为整个企业项目维持一个大的统一模型以获得模型完整性的做法，将不会有什么作为。解决方案不是那么明显的，因
为它远超乎我们所已经学习到的知识。不是试图保持一个迟早要四分五裂的大模型，我们应该做的是有意识地将大模型分解成数个较小的部
分。只要遵守相绑定的契约，整合得好的小模型会越来越有独立性。每个模型都应该有一个清晰的边界，模型之间的关系也应该被精确地定
义。

我们会提供一整套技术来保持模型的完整性。