在设计欠佳的软件里，子域和限界上下文(context)很难存在一对一的映射关系。-- 说明设计较好的，子域和限界上下文应该是一对一的映射关系。
在不同的模型中存在名字相同或者相近的对象，但是它们的意思缺不同。当模型被一个显示的边界所包围时，其中每个概念的含义便是确定的了。限界上下文主要是一个语义上的边界，我们应该通过这一点来衡量对一个限界上下文的使用正确与否。
不要尝试创建大而全的软件模型，其中每个概念在全局范围之内只有一种含义。项目都太庞大，太复杂，我们根本无法将所有的利益相关方聚集在一起，更别提达成一致。所以我们最好的方式是去正视这种不同，然后使用限界上下文对领域模型进行分离。
限界上下文并不旨在创建单一的项目资产，它并不是一个单独的组件、文档、或者框图。因此他并不是JAR或者DLL，但是这些可以用来部署限界上下文。
限界上下文主要用来封装通用语言和领域对象，也包含那些为领域模型提供交互手段和辅助功能的内容。
限界上下文的大小，可以包含多少领域模型中的基础部件：模块、聚合、领域事件、领域服务呢？原则是恰如其分，不多也不
少。
要创建一个恰到好处的限界上下文不是一件简单的事情。
可以把模型比喻成音乐，其中的音符（模块、聚合、事件和服务）的数量应该正好是设计所要求的那么多。
影响我们创建大小不正确的限界上下文的因数：1. 用架构来指导设计开发，而不是通用语言。这个时候我们通常会从技术层面而不是语义边界来思考问题。2. 根据开发任务的分配来拆分限界上下文。
创建限界上下文不能只是为了架构组件或者开发者资源考虑。
限界上下文可以与技术组件保持一致。将限界上下文想成技术组件并无大碍。但是我们要记住：技术组件并不能定义限界上下文。在我们使用IDE的时候通常一个限界上下文就是一个工程项目。