领域建模基础：什么是领域模型，限界上下文（Bounded Context）在缓存治理中的作用
在缓存一致性治理中，技术选型（Redis、Local Cache、一致性协议）往往被过度关注，而业务语义的边界划分才是决定缓存策略能否长期有效的根本因素。领域驱动设计（DDD）中的领域模型与限界上下文，正是将业务复杂度转化为可治理缓存边界的核心工具。
2.1 什么是领域模型
领域模型是对业务问题空间中核心概念、规则与逻辑的抽象表达。它不是数据库表结构，也不是API接口定义，而是业务专家与技术人员共同使用的“通用语言”载体。
| 维度 | 传统数据模型 | 领域模型 |
|---|---|---|
| 关注点 | 数据存储与关系 | 业务行为与规则 |
| 核心元素 | 表、字段、外键 | 实体、值对象、聚合、领域事件 |
| 缓存视角 | 缓存整张表或SQL结果 | 缓存聚合根或领域事件快照 |
| 一致性粒度 | 行级或表级 | 聚合边界内强一致，跨边界最终一致 |
关键认知：领域模型决定了“什么数据应该被缓存”以及“缓存失效的触发条件”。一个设计良好的领域模型，天然将缓存一致性问题的范围缩小到聚合边界之内。
2.2 限界上下文：缓存治理的“物理边界”
限界上下文（Bounded Context）是DDD中最重要的战略设计工具。它将大型系统拆分为多个语义内聚、边界清晰的子领域，每个上下文拥有独立的领域模型、数据存储和缓存策略。
在OpenAPI场景中，限界上下文直接对应缓存治理的隔离单元：
- 上下文内缓存：聚合根状态变更时，缓存失效范围可控，一致性容易保证。
- 跨上下文缓存：必须通过领域事件或API网关进行异步同步，接受最终一致性。
- 上下文边界：天然防止缓存雪崩扩散——一个上下文的缓存击穿不会直接拖垮另一个上下文。
实践原则：“一个限界上下文，一套缓存策略，一个一致性等级”。不要在同一个上下文中混合使用强一致和最终一致的缓存方案。
2.3 限界上下文在缓存治理中的核心作用
以下表格总结了限界上下文对缓存治理四个关键维度的直接影响：
| 治理维度 | 无限界上下文的问题 | 有限界上下文的方案 |
|---|---|---|
| 缓存键设计 | 全局扁平命名，冲突与覆盖风险高 | 上下文前缀隔离，如 order:{id}、payment:{id} |
| 失效传播 | 一个数据更新导致全系统缓存抖动 | 失效范围限制在上下文内部 |
| 一致性协议 | 被迫使用全局分布式锁或事务 | 上下文内用本地事务+缓存更新，跨上下文用事件驱动 |
| 团队协作 | 缓存策略耦合，修改需多方协调 | 每个团队独立管理自己上下文的缓存 |
2.4 领域模型与限界上下文的缓存映射关系
下图展示了在OpenAPI网关背后，两个限界上下文（订单上下文、支付上下文）如何通过领域模型驱动各自的缓存策略：
2.5 缓存治理中的上下文映射模式
在OpenAPI场景中，限界上下文之间的协作关系直接影响缓存一致性策略的选择。以下是三种最常见的上下文映射模式及其缓存治理含义：
| 映射模式 | 缓存治理策略 | 一致性等级 | 典型场景 |
|---|---|---|---|
| 防腐层（ACL） | 下游上下文缓存上游数据的转换副本，上游变更时通过事件刷新 | 最终一致 | 订单上下文缓存用户上下文的部分信息 |
| 共享内核 | 共享数据使用统一缓存服务，变更时广播失效 | 强一致（受限） | 多上下文共享的商品库存 |
| 事件发布/订阅 | 每个上下文独立缓存，通过领域事件异步同步状态 | 最终一致 | 支付完成 → 订单状态更新 |
常见陷阱：不要试图在多个限界上下文之间共享同一个缓存实例或缓存键空间。这会破坏上下文边界的隔离性，导致缓存失效的“蝴蝶效应”——一个上下文的热点数据更新可能引发全系统缓存雪崩。
2.6 从领域模型到缓存策略的推导路径
将领域模型转化为可执行的缓存治理方案，遵循以下四步推导路径：
- 识别聚合边界：确定哪些实体和值对象属于同一个聚合，聚合根是缓存的最小一致性单元。
- 定义上下文映射：明确当前上下文与外部上下文的协作模式，选择对应的缓存同步策略。
- 标记缓存热点：在领域模型中标注高频读取、低频写入的聚合根，优先使用本地缓存+Redis二级缓存。
- 设计失效触发器：将领域事件（如 OrderConfirmed、PaymentCompleted）映射为缓存失效或刷新动作。
总结：领域模型提供了“缓存什么”的业务语义，限界上下文划定了“缓存到哪”的物理边界。两者结合，让缓存一致性治理从“技术补丁”升级为“架构内置能力”。在后续章节中，我们将基于这一基础，深入OpenAPI场景下的具体缓存一致性治理模式与架构演进路径。