核心思想：分而治之，各个击破！
限界上下文是一个显式边界，领域模型便存在于边界之内。在边界内，通用语言中的所有术语和词组都有特定的含义，而模型需要准确地反映通用语言。
其实，从本质上来看，限界上下文是一个领域。
至于，DDD为什么是划分出限界上下文，而不是使用子域的子域来代替？
因为，限界上下文是一个比领域更加内聚的边界，限界上下文内的模型具有高度统一的业务属性，而领域，则是由不同业务属性组成，但这些业务属性都是为了一个共同目标。限界上下文，被包含在领域之中，领域具有一个或多个限界上下文。
举个例子，电商领域，包含了支付限界上下文、商品限界上下文、订单限界上下文、营销限界上下文、物流限界上下文，而支付限界上下文，只包含了与支付相关的内容，但无论是支付限界上下文，还是订单限界上下文，都是为电商领域服务，属于电商领域。
在微服务盛行的当下，限界上下文是划分微服务的理论依据。
注意的是，限界上下文并不等同于微服务。一个限制上下文只能包含在一个微服务之中，但是一个微服务却能包含多个限界上下文。
DDD的标准建议是，一个微服务只包含一个限界上下文。
但实际情况，好多团队在开发的过程是，往往偏离了DDD的建议标准，一个微服务中往往会包含了多个限界上下文的内容。这其中的缘由，说不清，理不尽。
很多时候，由于团队组织结构的原因（人员缺少），属于限界上下文A的功能，代码实现却在限制上下文B中。
有时候，限界上下文的内容非常少，出于成本考虑，便将这些小的限界上下文都放到同一个微服务中
怎么样划分限界上下文？
虽然明白了什么是限界上下文，但是怎么样划分限界上下文呢？这是一件很让人头痛的事情！
划分限界上下文，需要具备丰富的软件开发知识，同时也需要具备些丰富的业务知识，只有具备了这样的条件，才能准确地划分出合理的限界上下文。
上文讲述了通用语言，而通用语言细分到合适的粒度，有经验的开发者就可以从中得出限界上下文了。
以下，给出一个划分限界上下文的示例。
通用语言划分到这种粒度，就能划分出限界上下文了吗？一般来说，是可以确定出限界上下文了。
公告，图书馆的公告内容比较简单，细分下去有：通知类公告、活动类公告。图书馆公告的业务比较单一，所以划分到这个粒度，公告限界上下文就可以确立。
图书借阅，细分下去有：图书借出、图书归着。图书借出又可细分：短期借出、长期借出……。如果，图书借阅的业务不会有很多种，那么，图书借阅限界上下文可以确立。
库存管理，细分有：入库管理、出库管理。如果入库管理很复杂、出库管理也很复杂，那么，就需要将入库管理和出库管理细分下去，一直分到满意的粒度为止。在细分后的通用语言基础上，决定是否有必须划分入库管理限界上下文、出库管理限界上下文，还是只划分库存管理限界上下文。
而通用语言，天生就具有划分限界上下文的属性。
