每一个模型都有一个上下文。在我们处理一个独立的模型时，上下文是固定的。我们不需要去定义它。当我们创建一个假定要和其他
软件，比如一个遗产应用，交互的应用时，很明显新的应用有自己的模型和上下文，它们和遗产模型和它的上下文相分离。它们不能
被合并、混合或者模糊定义。所以当我们开发大的企业应用时，需要为每一个我们创建的模型定义上下文。

在任何大型项目中都存在多个模型。如果基于不同模型的代码被合并，软件就变得不稳定、不可靠而且很难理解。团队之间的沟通也
会不通畅。在哪些上下文里不应该有模型通常都不是非常明确的。如何把一个大的模型分解成小的部分没有什么具体的公式。尽量把
那些相关联的以及能形成一个自然概念的因素放在一个模型里。模型应该足够小，以便能分给一个团队去实现。团队协作和沟通如果
更畅通，会有助于开发人员共同完成一个模型。模型的上下文是一个条件集合，用这些条件可以确保应用在模型里的条款都有一个明
确的含义。

这儿主要的思想是定义模型的范围，画出它的上下文的边界，然后尽最大可能保持模型的一致性。要在模型涵盖整个企业项目时保持
它的纯洁是很困难的，但是在它被限定到一个特定区域时就相对容易很多。要在应用到模型的地方明确定义上下文。在团队组织里明
确定义边界，在应用的具体部分明确定义用法，以及像代码库和数据库Schema 的物理显示。保持模型在这些边界里的严格一致，不
要因外界因素的干扰而有异动。

被界定的上下文不是模型。界定的上下文提供有模型参与的逻辑框架。模块被用来组织模型的要素，因此界定的上下文包含模块。
当不同的团队不得不共同工作于一个模型时，我们必须小心不要踩到别人的脚（译者注：意思为各司其职，不越界）。要时刻意识到
任何针对模型的变化都有可能破坏现有的功能。当使用多个模型时，每个人可以自由使用自己的那一部分。我们都知道自己模型的
局限，都恪守在这些边界里。我们需要确保模型的纯洁、一致和完整。每个模型应能使重构尽可能容易，而不会影响到其他的模型。
而且为了达到纯洁的最大化，设计还要可以被精简和提炼。

有多个模型时总是会付出些代价。我们需要定义不同模型间的边界和关系。这需要额外的工作和设计付出，以及可能出现的不同模型
间的翻译。我们不能在不同模型间传递任何对象，也不能在没有边界的情况下自由地激活行为。但这并不是一个非常困难的任务，而
且带来的好处证明克服这些困难是值得的。

比如，我们要创建一个用来在互联网上卖东西的在线应用。这个应用允许客户注册，然后我们收集他们的个人数据，包括信用卡号
码。数据保存在一个关系型数据库里面。客户被允许登录，通过浏览网站寻找商品，下单等。不论在什么时候下单，应用都需要触发
一个事件，因为有人要邮寄需求的货物。我们还想做一个用于创建报表的报表界面，所以还应该能监视已有的货物数量、哪些是客户
感兴趣购买的、哪些是不受欢迎的等信息的状态。开始的时候，我们用一个模型涵盖整个在线应用的领域。很自然地就会这样做，因
为毕竟我们被要求创建一个大的应用。但是仔细考虑手头的任务之后，我们发现这个E 商店应用其实和报表并不是那么相关联。它们
有不同的考虑，在不同的概念下操作，甚至需要用到不同的技术。

唯一共通的地方是客户和商品的数据都存储在数据库里，两个应用都访问到它们。

推荐的做法是为每一个领域创建一个独立的模型，一个为在线交易，一个为报表。它们两个可以在互不干涉的情况下继续完善，甚
至可以变成独立的应用。也许报表应用会用到在线交易（ ecommerce）应用应该存储在数据库里的一些特定数据，但多数情况
下它们彼此独立发展。

还需要有个通讯系统来通知仓库管理人员订单信息，这样他们就可以邮寄被购买的货物。邮寄人员也会用到一个可以提供给他们详细
的关于所购买的物品条目、数量、客户地址以及邮寄需求等信息的应用。不需要使在线商店（e-shop）模型覆盖两个活动领域。对在
线商店而言，用异步通讯的方式给仓库发送包含购买信息的Value对象要相对简单的多。这样就明确地有两个独立开发的模型，我们
只需要保证它们之间的接口工作良好就可以了。