2. 核心概念回顾：领域、子域、限界上下文（Bounded Context）的定义及其在服务拆分中的角色
在深入缓存一致性与服务边界设计之前，必须统一对领域驱动设计（DDD）三大核心概念的理解。这三个概念构成了从业务需求到技术实现之间的桥梁，也是后续所有架构决策的基石。
2.1 领域（Domain）与子域（Subdomain）
领域 是指组织所从事的业务范围或问题空间。在软件系统中，领域通常对应一个完整的业务能力集合，例如“电商平台”、“银行核心系统”或“医疗信息管理”。
子域 是对领域的进一步分解，用于划分业务问题的优先级和关注点。DDD 将子域分为三类：
| 子域类型 | 定义 | 业务价值 | 典型示例（电商） |
|---|---|---|---|
| 核心子域 | 组织最核心、最具竞争力的业务逻辑 | 高，差异化优势来源 | 订单履约、定价引擎 |
| 支撑子域 | 支持核心业务但非核心竞争力的部分 | 中，可考虑外包或采购 | 库存管理、物流配送 |
| 通用子域 | 行业通用、无差异化需求的业务 | 低，优先使用现成方案 | 用户认证、通知发送 |
架构启示： 缓存策略的投入应与子域类型匹配。核心子域需要强一致性缓存方案（如分布式锁+缓存），而通用子域可接受最终一致性（如 TTL 缓存）。
2.2 限界上下文（Bounded Context）
限界上下文 是 DDD 中最关键的战术模式。它定义了模型应用的边界，每个限界上下文内部拥有独立的统一语言（Ubiquitous Language），外部通过明确的接口进行通信。
限界上下文的核心特征：
- 模型独立性： 同一个业务概念在不同上下文中可以有不同含义和结构（例如“用户”在“订单上下文”中是一个买家 ID，在“营销上下文”中是一个画像标签集合）。
- 边界清晰： 上下文之间通过防腐层（Anti-Corruption Layer, ACL）或发布事件进行集成，避免内部模型污染。
- 自治性： 每个上下文拥有自己的数据存储、缓存策略和部署单元。
关键认知： 限界上下文是微服务拆分的直接映射单元。一个限界上下文通常对应一个或多个微服务，而缓存一致性问题往往发生在上下文之间的数据交互点上。
2.3 三者在服务拆分中的角色
领域、子域和限界上下文共同构成了服务拆分的决策框架。下图展示了从业务领域到微服务边界的映射路径：
2.4 服务拆分原则与缓存一致性影响
基于上述概念，服务拆分应遵循以下原则，这些原则直接影响缓存一致性的设计复杂度：
- 按限界上下文拆分： 每个微服务对应一个限界上下文，确保内部模型完整、外部依赖最小化。缓存失效范围被限制在上下文内部。
- 子域优先级驱动： 核心子域对应的服务应拥有最强的数据一致性保障（如强一致性缓存），而通用子域可放宽至最终一致性。
- 上下文映射关系决定集成方式： 不同上下文之间的协作模式（如发布-订阅、RPC、消息队列）决定了缓存更新的传播路径和延迟容忍度。
常见陷阱： 将“数据库表”作为服务拆分依据，而非“业务边界”。这会导致跨服务的事务操作频繁，缓存一致性维护成本急剧上升。始终从限界上下文出发定义服务边界。
2.5 概念对比总结
| 概念 | 关注点 | 粒度 | 对缓存设计的影响 |
|---|---|---|---|
| 领域 | 业务问题空间 | 最粗 | 确定缓存策略的总体目标（如电商追求高可用 vs 金融追求强一致） |
| 子域 | 业务优先级与价值 | 中等 | 决定缓存一致性等级（强一致 vs 最终一致）的分配 |
| 限界上下文 | 模型边界与统一语言 | 最细 | 定义缓存的作用域、失效范围以及跨服务缓存同步的接口 |