限界上下文（英文：Bounded Context，简称BC）。从字面上就知道限界上下文（BC）有两层意思：
- Bounded即有边界的，限界就是领域的边界；
- Context即上下文相关的，上下文是指语义环境；
限界上下文的定义：用来封装通用语言和领域对象，提供上下文环境，保证在领域之内的一些术语、业务相关对象等（通用语言）有一个确切的含义，没有二义性。
二义性例子
例子：
在一个明媚的早晨，孩子起床问妈妈：“今天应该穿几件衣服呀？”
妈妈回答：“能穿多少就穿多少！”
那到底是穿多还是穿少呢？
如果没有具体的语义环境，还真不太好理解。
但是，如果你已经知道了这句话的语义环境，比如是：寒冬腊月或者是炎炎夏日，那理解这句话的涵义就会很容易了。
所以语言离不开它的语义环境。
大杂烩的业务概念歧义
再举个例子：
- 营销部门通过投放广告和参加展会能留下线索；
- 客服部门通过在线接待系统回到陌生访客的问题也能留下线索；
- 销售部门通过跟进线索从而发现商机。
这里其实出现了三个『线索』概念，看起来都是在讲线索，但其实它们各有各的不同。
- 营销部门的线索可能只是对你的产品有点兴趣，只是留下了一个联系方式（不知道能不能联系上）；
- 客服部门的线索有些只是网民访问你的网站留下来的记录，可能连联系方式也没留下；
- 销售部门面对的线索是能联系的上，甚至对产品有一定购买意向；
如果把这三个线索用一个业务概念来表达，那么不同部门人员之间的沟通往往会出现概念之间的歧义甚至冲突，系统的实现也会变得复杂且容易变化。
BC就是用来区分这种特殊性的。通过BC把有歧义的业务概念隔离开，各自回到各自的BC中，在BC里面形成统一的命名。
语言交流层面如果发现障碍和歧义也侧面反映了BC划分的不正确性。
同一个对象在不同阶段有不同涵义
举个例子：
电商领域的商品在不同的阶段有不同的术语，在销售阶段是商品，而在运输阶段则变成了货物。
同样的一个东西，由于业务领域的不同，赋予了这些术语不同的涵义和职责边界，这个边界就可能会成为未来微服务设计的边界。
这个边界定义了模型的适用范围，使团队所有成员能够明确地知道什么应该在模型中实现，什么不应该在模型中实现。
限界上下文拆分多细？
还是要回到定义：为了避免通用语言或领域对象有二义性时用限界上下文。
而领域对象是要看你要解决什么问题的？
- 对电商来说，关注的销售商品，这时候桃子也就分不同类别、不同级别的就可以了（好的定价更高）。
- 而长途运输场景下，则是看一箱箱的桃子。
- 上面这两个场景都不会看一个个具体的桃子。拆分太细对解决问题没有任何帮助，反而增加相关成本。
- 当桃子中有坏桃子，我们需要挑出来扔掉时，我们才需要一一识别。
总结
通过上下文环境，确保领域内的术语、业务相关对象没有二义性，这就是限界上下文。
