从我们在大学学习建模语言UML开始，便了解在系统设计过程中，一个通用的语言对计算机领域交流的重要性。同样在DDD领域，通用语言应该反映领域专家对业务领域内部工作和基本原则的心理模型。

各种不同的模型以及边界上下文

在业务领域中，每个子业务都有自己的专业术语，这些专业术语之间可能会有共同点也可能完全不相关，我们讲这些专业的术语根据业务分配到不用的业务，对业务的描述上下文进行划分，那么这就产生了业务的有界上下文。
 只要它在每个有限的上下文中具有单一的含义，每个细粒度的通用语言都是一致的，并遵循领域专家的基础模型。

 模型的边界和术语定义

一个模型不能没有边界而存在，它会扩展成为现实世界的复制品。这使得定义模型的边界——它的有界上下文——成为建模过程的固有部分。业务术语在边界上下文的范围内是普遍的，这种术语专注于描述被边界上下文所包含的模型。

边界上下文的范围

边界上下文的边界需要再一个合适的范围，如果边界上下文太小，设计中就会引入更多的集成开销。类似于微服务拆的过小，可是如果过大，那么业务领域之间的边界将变得不明显。因此，决定边界上下文的大小应根据特定的问题领域而定。有时，使用较宽的边界会更清晰，而其他时候，将其进一步分解会更有意义。

需要注意的是，将一个完整的功能分解为多个边界上下文。这种划分会阻碍每个上下文独立演进的能力。相反，相同的业务需求和变更将同时影响边界上下文，并需要同时部署变更。为了避免这种无效的分解，请识别一组在同一数据上运行的一致用例，并避免将它们分解为多个边界上下文。

有界上下文与子域

那么有界的上下文和子域之间又有什么关系，子域类似于一组相互关联的用例。作为架构师，我们正在分析业务域以识别子域。 选择模型边界是一项战略性设计决策，我们决定如何将业务域划分为更小的、可管理的问题域。 
重要的是要记住，子域是发现的，有界上下文是设计的。子域由业务策略定义。然而，我们可以设计软件解决方案及其有界上下文来处理特定项目的上下文和约束。 

业务边界

关于上下文边界这种模型在DDD中主要应用于定义物理边界和所有者边界。

物理边界一般指的是有界上下文的模型边界，有界上下文的每个子域都是一个逻辑边界。在不同的编程语言中也被定义为不同的名字：命名空间、模块、包等。

所有者边界可以理解我们利用模型边界和有界上下文来定义我们技术团队之间的分工以及合作。不要让两个团队在相同有界上下文内工作，团队之间应该通过约定的通信协议来继承整体模型和系统。

小结

业务领域的定义和管理一般由领域专家来负责，领域专家需要整理业务领域的术语来描述业务的有界上下文，定义子域边界。在公司层级上这是非常重要的战略决策，影响着后续团队的规划方向。理论情况下，一个团队可以处理多个有界上下文，我们尽量不要让多个团队在一个有界上下文即一个业务子域中工作。业务子域之间的协作也要约定通信协议。