边界上下文是领域驱动设计的一个重要模式。它是领域驱动设计中策略设计部分的关注点-这部分是关于处理大型模型和团队的。领域驱动设计通过把大型模型分割成不同的上下文并且明确定义它们之间的关系来处理大型模型。

      领域驱动设计是基于背后领域的模型来设计软件。一个模型作为一种统一语言帮助软件开发人员和领域专家之间交流。它也作为软件自身设计的概念基础—如何分解成对象或者方法。为了有效性，一个模型必须是统一的即它是内部一致的已至于在内部没有相矛盾的点。

      当你试图对一个更大的领域建模，构建统一的模型会越来越困难。在一个大型组织的不同部门，不同小组的人可能使用略微不同的词汇。模型的精确性很快会遇到这种问题，常常导致很多疑惑。这种疑惑往往是因为关注于领域的中心概念。在我职位生涯的早期我做过一些与电力相关的工作—在这里”米”在公司的不同部门代表不同的东西：它是输电网与地区之间，输电网与用户之间的连接，它是物理上米的意思。这些微妙的多义词可能在沟通中比较缓和，但是对于计算机的精确性并不能这样。我一次又一次的发现这个问题发生在一些多义词上，比如“用户”和“产品”。

      在那段年轻岁月，我们被建议在整个业务中构建一个统一的模型，但是DDD认为我们所学习的”对一个大型系统，领域模型的完全统一将是不可行的或者不划算的“。所以取而代之，DDD把大型系统分割成边界上下文，每一个都有一个统一模型—本质上是构建多个重要模型（MultiCanonicalModels）的方法。

      边界上下文即包含不相关的概念（例如一个售后票据仅仅存在于用户售后上下文中）同时也共享一些概念（例如产品和用户）。在集成的时候不同的上下文可能有一些相同的概念在不同的机制下有完全不同的模型映射到这些多义词上。很多DDD模式探索了上下文之间关系的可替换方式。

      多种因素影响上下文之间的边界划定。比较常用的重要方法是人类文化，因为模型作为一种统一语言，在语言改变的时候你需要一个不同的模型。你也可以在相同的领域上下文中找到多个上下文，例如一个应用中内存和关系数据库模型的分离。通过不同的方式描述模型，边界就被设置。

      DDD的策略设计部分描述了多种方法，你可以使用它处理上下文之间的管理。使用一个上下文地图来描述这些关系是非常值得的。

进一步阅读

DDD的权威来源是Eric Evans的书。对于软件著作来说它不是最容易读的，但是它包含了大量实质性的研究。上下文边界在第4部分。

Vaughn Vernon的《Implementing Domain-Driven Desgin》书关注于策略设计。第2章详细介绍了一个领域怎样被分成边界上下文，第3章是绘制上下文地图的最好资源。

我喜欢一些老但是仍然有用的软件书籍。我最喜欢的书之一是William Kent的《Data and Reality》。我仍然记的他对油井的多异性的简短描述。

Eric Evans描述了一个边界上下文的明确使用如何允许团队使用冒泡上下文把一个新功能移植到一个遗留系统中。例子描述了相关的边界上下文如何有相同的和不同的模型以及如何在它们之间做对应。

作者：Martin Fowler

原文链接：http://martinfowler.com/bliki/BoundedContext.html