限界上下文就是限定边界的上下文，一方面，为通用语言和领域模型限定了边界，在边界规定的范围内，所涉及的概念是唯一的；另一方面，为程序代码规定了边界，这个边界可以是逻辑上的（程序包）或者物理上的（可独立发布的模块，或可独立运行的应用）。
限界上下文是Bounded Context的中文翻译，也翻译为有界上下文或者其它的。要理解这个概念还是从最基本的翻译开始。Bounded比较好理解，有界限的，限定范围的都可以，关键是对Context的理解。《新英汉词典》中Context的解释是：1）（文章的）上下文，前后关系；2）（事物等发生的）来龙去脉。“上下文”在《现代汉语词典》中的解释是“指文章或说话中与某一词语或文句相连接的上文和下文”。所以，中文的“上下文”是特指语言上的关系，而Context不仅指语言上的，还指事物等的前后关系和来龙去脉。 限界上下文指的是限定了边界的业务范围。“限界上下文”定义了业务的边界，在这个边界划定的范围内，所有的业务名词含义是统一的，业务规则是一致的。“限界上下文”也明确了软件模型的范围，对代码库、数据库模式等方面也显式地设置边界。
“限界上下文”不是抽象的概念，不仅在业务划分时起作用，对软件结构和开发也有较强的约束。如果对“限界上下文明确了软件模型的范围”换一种说法，就会看到它软件开发的约束：软件模型只在规定的“限界上下文”中起作用，在其它限界上下文中不应该起作用。这就限制了跨限界上下文模型的存在，如果两个限界上下文需要数据交换或者功能调用，必须通过某种映射进行，不能跨过边界直接调用。
在项目中，我们经常遇到业务概念不统一的情况，即使在一个项目中，涉及到的不同部门的用户对同一个业务概念的解释是不同的，比如“库存”，在供应部门的概念中，是指仓库中实际存储的原料，而在生成部门的概念中，还包括了生产线上的“在制品”,而在财务部门，可能仅以采购合同为准计算库存。如果软件设计时坚持将“库存”概念标准化，就会带来一系列的问题：以哪个部门的口径为准，由哪个领导牵头协调……如果非技术因素掺和进来，可能需求分析刚开始，项目就要寿终正寝了。而从领域驱动设计的角度出发，就会发现，同一个业务概念在不同的限界上下文中的含义本来就不相同，不能也没有必要进行统一，合理的做法是在不同的限界上下文中规定这些概念的含义，将其明示化，如果需要集成，明确概念在不同的限界上下文之间的转换关系。
更多的内容可以参考《领域驱动设计.Net实践》一书。