定义
Bounded Context 是领域驱动设计中战略设计的重要组成部分，一定程度上决定了系统的逻辑架构以及集成方式。
基于康威定律，Bounded Context 的划分还可能会影响进行项目开发实施的组织的结构。
DDD 社区将 Bounded Context 定义为：
应该显式地定义某个模型所应用的上下文。还应该在团队组织、应用中特定部分的使用以及像代码库和数据库模式等物理表现等方面显式地设定边界。要保持边界中模型的严格一致，而不要受外界问题的影响与干扰。
这段话在说的无非是「边界」，通过为领域模型划定合理的边界，就可以降低设计与开发的复杂度。此外，边界还能够划分知识的层次，例如对外而言，可以只保障暴露在边界外接口的一致性，以及关注它们之间的集成方式。边界之内则自成一体，可以独立演化，甚至可以包容一到多个遗留模块。
常见问题
正是因为 Bounded Context 带来的隔离性，Juelin Lerman才认为：「把一个将大量的类放在一个上下文中的独立模型分解为多个较小的模型是有好处的。Bounded Context 创建的模型较小，而且内聚性更高，同时维持了模型之间的边界。」
好处听起来都是好的，但是难免会有下面这些问题：
如何确定或划分 Bounded Context？ Bounded Context 是否具有层次？ Bounded Context 划分的边界是逻辑的，还是物理的？ Bounded Context 之间的通信方式？
也难怪在文章《DDD: The Bounded Context Explained》中 Mike 要说，Bounded Context 是 DDD 中最难解释的原则，但或许也是最重要的原则。可以说，没有 BC，就不能做 DDD。在了解 Aggregate Root、Aggregate、Entity 等概念之前，需要先了解 BC。
Vaughn Vernon 的Implementing Domain-Driven Design解释如下：
Bounded Context是一个显式的边界，领域模型便存在于这个边界之内。领域模型把通用语言表达成软件模型。创建边界的原因在于，每一个模型概念，包括它的属性和操作，在边界之内都具有特殊的含义。
这里是从设计原则上来规约出 Bounded Context 的定义：
- 它是模型概念，与实现无关，是高层的抽象机制
- 具有自己独立的边界，是自治的，遵循高内聚、松耦合
- 不同的 Bounded Context 之间的关系决定它们之间的协作与通信方式
- 它与 Domain 应为一一对应关系
- 一个上下文意味着一个专有的职责