限界上下文目的：
不在于如何划分边界 而在于如何控制边界
对于统一语言：
限界上下文是语言的边界
对于领域模型：
限界上下文是模型的边界
语言的边界以及模型的边界可以 界定问题域
对于系统架构：
限界上下文确定了应用边界和技术边界
限界上下文 分离了业务边界
目的：约束不同上下文的领域模型
例如 电商中的产品：
1 采购上下文：关注产品的进价、最小起订量与供货周期
2 市场上下文：关心产品的品质、售价，以及用于促销的精美图片和销售类型
3 仓储上下文：关心产品放在仓库的哪个位置，产品的重量与体积，是否易碎品以及订购产品的数量
4 推荐上下文：关注的是产品的类别、销量、收藏数、正面评价数、负面评价数
不应该将这一概念建模为单个类，否则就可能导致不同限界上下文对应的领域模型为了代码重用，而共享这个共同的 Product 类，导致限界上下文之间产生代码的耦合
产品（Product）实体的设计也违背了“单一职责原则（SRP）”，它包含了太多本应分离的职责，适用于不同的上下文，从而变成了一个臃肿的上帝类
（产品对标基础服务组的人员）
解决方案：
将产品看做是参与业务场景的角色，
遵循接口隔离原则（ISP）对 Product 实体类进行抽象，抽象出多个角色接口
方案一：让定义的 Product 类去实现这多个接口，体现了“大对象小角色”的设计思路。
引入一个产品上下文，然后在其内部定义 Product 类去实现这些接口。
缺点：致了产品上下文同时依赖其余四个限界上下文，形成了架构层面上限界上下文之间不必要的耦合
为了避免重复，我们引入了耦合，这种设计上的顾此失彼是不可取的。
方案二：让每一个限界上下文拥有自己的领域模型，该领域模型仅仅满足符合当前上下文需要的产品唯一表示
不同的限界上下文都存在相同的 Product 领域模型，但由于有了限界上下文作为边界，使得我们在理解领域模型时，是基于当前所在的上下文作为概念语境的（虽然都是Product，但是在不同上下文中角色不同）
优点：
保证了限界上下文之间的松散耦合
维持限界上下文各自领域模型的一致性
工作边界被限界上下文明确
如果有两个限界上下文的工作，分配给两个不同的团队。分配工作时，却没有按照限界上下文的边界去组建团队，
即每个团队会同时承担两个限界上下文的工作。试想，这会造成多少不必要的沟通成本浪费
能够将团队与限界上下文重合，就能够降低沟通成本，打造高效的领域特性团队，专注于属于自己的限界上下文开发。
限界上下文封装了应用边界
划分限界上下文：
1：业务边界的确立
2：控制技术复杂度，兼顾技术实现
高并发
外卖系统的订单业务在某个特定的时间段比如中午 11 点到 13 点会达到订单量的高峰值
将订单业务从整个系统中剥离出来，作为一个单独的限界上下文对其进行设计，就可以从物理架构上保证它的独立性，在资源分配上做到高优先级地扩展，在针对领域进行设计时，尽可能地引入异步化与并行化，来提高服务的响应能力
功能重用
账户管理并非系统的核心领域，但与账户相关的业务逻辑却相对复杂。从功能重用的角度考虑，我们应该将账户管理作为一个单独的限界上下文，以满足不同核心领域对这一功能的重用，避免了重复开发和重复代码。
实时性
电商系统中，商品自然是核心，而价格（Price）则是商品概念的一个重要属性。倘若仅仅从业务的角度考虑，在进行领域建模时，价格仅仅是一个普通的领域值对象
倘若该电商系统的商品数量达到数十亿种，每天获取商品信息的调用量在峰值达到数亿乃至数百亿次时，价格就不再是业务问题，而变成了技术问题。对价格的每一次变更都需要及时同步，真实地反馈给电商客户
专门针对价格领域提供特定的技术方案，例如，通过读写分离、引入 Redis 缓存、异步数据同步等设计方法。此时，价格领域将作为一个独立的限界上下文，形成自己与众不同的架构方案，同时，为价格限界上下文提供专门的资源，并在服务设计上保证无状态，从而满足快速扩容的架构约束。
第三方服务集成
背景：一个电商系统需要支持多种常见的支付渠道，如微信支付、支付宝、中国银联以及各大主要银行的支付。电商系统需要与这些第三方支付系统进行集成。不同的支付系统公开的 API 并不相同，安全、加密以及支付流程对支付的要求也不相同。
目标：
1 为支付服务的客户端提供完全统一的支付接口，以保证调用上的便利性与一致性（从上游角度考虑）
2 能解除第三方支付服务与电商系统内部模块之间的耦合，避免引起“供应商锁定（Vender Lock）”，也能更好地应对第三方支付服务的变化。（从下游角度考虑）
方法：
将这种集成划分为一个单独的限界上下文。
遗留系统
避免已有模型对新开发模块的影响，我们应该将这些已有功能视为具有技术债的遗留系统，并将该遗留系统整体视为一个限界上下文。
