限界上下文（Bounded Context）
限界上下文是领域驱动设计中划分业务边界的关键概念，就像城市中的不同功能区：
通俗理解
- 城市行政区划（每个区有明确的职责范围）
- 企业部门设置（每个部门负责特定业务）
- 超市商品分区（生鲜、日用品、家电等区域）
这些例子都展示了如何通过边界划分来管理复杂性。
让我们聊聊限界上下文
想象一下，限界上下文就像是我们团队中的不同部门，每个部门都有自己的专业术语和工作方式。在领域驱动设计中，它帮我们划清边界，让每个业务模块都能用自己最舒服的方式运作，不会因为术语混淆而闹笑话。
它的几个特点
- 说同一种语言：就像市场部和研发部对"产品"的理解可能不同，限界上下文确保团队内部术语一致
- 各司其职：每个上下文就像公司的一个部门，专注做好自己的事情
- 明确边界：部门之间需要协作时，就像我们定好接口文档一样清晰
- 独立运作：技术实现上可以有自己的特色，就像不同部门用不同的办公软件
更多案例
电商平台案例
订单上下文 - 购物车的终点站
- 这里说的"订单"可不是随便什么单子，而是指用户点击"立即购买"后生成的正式交易订单
- 主要职责：
- 创建订单时，要检查商品库存、计算总价、生成订单号
- 跟踪订单状态：从"待付款"到"已发货"再到"已完成"
- 处理取消和退款申请，但实际退款操作要交给支付上下文
- 典型场景：
- 用户下单后30分钟未支付，自动取消订单
- 商家发货后更新物流信息
库存上下文 - 仓库大管家
- "库存"在这里特指实际可售卖的商品数量，不是虚拟库存哦
- 核心功能：
- 实时库存扣减：用户下单时立即锁定库存
- 库存预警：当商品存量低于安全库存时自动提醒采购
- 多仓库调拨：根据销售情况智能分配库存
- 有趣细节：
- 预售商品和有货商品使用不同的库存计算逻辑
- 大促期间要处理瞬时高并发库存查询
支付上下文 - 资金流转中心
- 这里是与支付宝、微信支付等第三方对接的主战场
- 关键流程：
- 支付：生成支付参数、验证支付结果、更新订单状态
- 退款：处理全额/部分退款，记录退款流水
- 对账：每天凌晨与支付平台核对交易数据
- 特别注意：
- 支付超时、重复支付等异常情况处理
- 不同支付渠道的手续费计算规则不同
银行系统案例
账户上下文 - 你的金融身份证
- 这里的"账户"可不是泛指，而是严格定义的银行账户实体
- 核心功能：
- 开户：收集KYC信息、设置账户类型、生成账号
- 账户管理：冻结/解冻、升降级、设置限额
- 账户查询：余额、流水、基本信息
- 业务规则：
- 不同账户类型(储蓄、理财、对公)有不同的属性
- 境外账户和境内账户遵循不同的监管要求
交易上下文 - 资金的搬运工
- 负责处理各种资金流转操作
- 主要交易类型：
- 行内转账：实时到账，几乎零成本
- 跨行汇款：通过央行支付系统处理
- 外币兑换：涉及汇率计算和外汇管制
- 技术挑战：
- 保证ACID，特别是在分布式环境下
- 处理大额交易的特殊风控流程
风控上下文 - 金融系统的守夜人
- 7×24小时监控所有可疑交易
- 典型风控规则：
- 凌晨大额转账
- 短时间内多次小额试探性交易
- 交易地点突然切换到境外
- 工作方式：
- 实时拦截高风险交易
- 事后生成风险报告供人工复核
- 定期更新机器学习模型的特征库
实施建议
- 从业务能力分析入手识别潜在上下文
- 通过事件风暴工作坊明确上下文边界
- 优先解耦高频变更的领域
- 为跨上下文通信设计防腐层
- 建立上下文映射图可视化关系
主要特点
- 语义边界：统一语言和业务概念
- 技术边界：独立的技术实现
- 职责单一：每个上下文专注一个业务领域
- 明确接口：定义清晰的交互契约
示例
java
// 电商系统中的订单上下文
class Order {
// 订单上下文特有的业务逻辑
void confirm() { /*...*/ }
void cancel() { /*...*/ }
}
// 支付上下文
interface PaymentService {
// 明确的支付接口
PaymentResult process(PaymentRequest request);
}设计原则
- 业务优先：根据业务能力划分边界
- 自治性：上下文内部高度内聚
- 最小依赖：减少上下文间耦合
- 演进能力：支持边界动态调整
限界上下文是一个领域的边界，它定义了一个领域的边界，在这个边界内，我们可以定义这个领域的模型，这个领域的业务规则，这个领域的服务，这个领域的接口，这个领域的技术实现。