1. 引言
限界上下文可以拆分为两个词，限界和上下文。
限界：是指一个界限，具体的某一个范围。
上下文：个人理解就是语境。
比如我们常说的段子：
“我想静静。”
这个句子一般是想表达“我想静一静”的意思。但是我们却把它玩笑成“静静是谁？”。
可见上下文语境很重要。
这个例子只是个开胃菜，我们接着往下看。
2. 案例分析
整个应用程序之内的一个概念性边界。
边界之内的每种领域术语、词组或句子--也即通用语言，都有确定的上下文含义。
边界之外，这些术语可能表示不同的意思。
每次看到这种解释就头大。我们还是结合我们的案例来聊一聊吧。
根据上一节对领域的剖析，我们把案例主要拆分成几个子域，其中销售子域是核心域，商品子域和物流子域为支撑子域。在这三个子域中，都要和商品打交道。如果把商品抽象为Product对象的话，按我们一般的常规思路（抛开子域的划分）来说，不管是商品销售还是发货，我们都可以共用同一个Product对象。
但在DDD中，在商品子域和销售子域中，可以共享这个Product对象，但在物流子域，就有点大材小用。为什么呢？因为毕竟物流子域关注的是商品的发货处理和物流跟踪。针对发货流程而言，我只关心商品的数量、大小、重量等规格，而不必了解商品的价格等其他信息。所以说物流子域应该关注的是货物的发货处理而不是商品。
那为什么我们之前的开发思路会共用同一个Product对象呢？
答案很简单，没有进行领域的划分。把整个项目一概而论，统一建模导致的结果。
在DDD的思想下，当划分子域之后，每个子域都对应有各自的上下文。在销售子域和商品子域所在的上下文语境中，商品就是商品，无二义性。在物流子域的上下文语境中，我们也可以说商品的发货处理，但这时的商品就特指货物了。确定了真实面目之后，我想我们也会不由自主的抽象一个新的Cargo对象来处理物流相关的业务。这也是DDD带来的好处，让我们更清晰的建模。
3. 限界上下文的命名
限界上下文只是一个统一的命名，在我们划分子域后，每个子域一般对应一个上下文，也可以对应多个上下文。但如果子域对应多个上下文的时候，就要考虑一下是不是子域能否继续划分。
命名方式很简单，领域名+上下文。
比如我们的销售子域对应销售上下文，物流子域对应物流上下文。
4. 总结
通过我们上面的举例分析，限界上下文也并不是一个高深的概念。
用官话来说限界上下文主要用来封装通用语言和领域对象。
按我个人的理解它就是用来为领域提供上下文语境，保证在领域之内的一些术语、业务相关对象等（通用语言）有一个确切的含义，没有二义性。
参考资料
What are Bounded Contexts and Context Maps in Domain Driven Design?
2018.1.27 更新
观察角度的不同,限界上下文划定的边界也有所不同。大体可以分为如下三个方面:
领域逻辑层面：限界上下文确定了领域模型的业务边界，维护了模型的完整性与一致性,从而降低系统的业务复杂度。
团队合作层面：限界上下文确定了开发团队的工作边界，建立了团队之间的合作模式,避免团队之间的沟通变得混乱，从而降低系统的管理复杂度。
技术实现层面：限界上下文确定了系统架构的应用边界，保证了系统层和上下文领域层各自的致性，建立了上下文之间的集成方式，从而降低系统的技术复杂度。
这三种边界体现了限界上下文对不同边界的控制力，业务边界是对领域模型的控制,工作边界是对开发协作的控制，应用边界是对技术风险的控制。引入限界上下文的目的：其实不在于如何划分边界，而在于如何控制边界。
--引用自«张逸：领域驱动战略实践»
怎么理解呢，就是说对限界上下文的划分可以从三个角度去看。
- 从领域逻辑的角度，即根据业务知识进行划分，比如将电商项目划分为订单、商品、促销、物流、售后等限界上下文。
- 从技术实现角度，比如为了解决系统的高并发，决定引入缓存，那就可以考虑将缓存服务抽离为一个独立的限界上下文作为支撑。
- 从团队合作的角度，即回到了以人为本的思想。比如根据领域业务划分的限界上下文组建领域特性团队进行职责划分以确定团队协作边界。明确的团队边界有利于团队的沟通和协作。
