4. 服务边界定义：微服务架构下的服务边界划分原则、数据所有权与缓存域的关系

在微服务架构中，服务边界的定义直接决定了数据所有权、缓存策略以及跨服务通信的复杂度。错误的边界划分会导致缓存穿透、数据不一致和系统耦合度急剧上升。本节从领域驱动设计（DDD）出发，系统阐述服务边界划分的核心原则，并揭示数据所有权与缓存域之间的内在关联。

4.1 服务边界划分三大原则

服务边界不是随意切割的，而是基于业务领域、数据变更频率和一致性要求三个维度综合决策的结果。下表总结了三大原则及其对缓存设计的影响：

4.2 数据所有权模型：写主与只读引用

数据所有权是服务边界的自然延伸。每个服务对其拥有的数据拥有“写主”权限，其他服务只能通过API或事件获取数据的只读副本。这种模型直接决定了缓存域的范围：

• 写主（Write Owner）： 服务拥有数据的完整生命周期管理权，包括创建、更新、删除。该服务内的缓存是“权威缓存”，可直接写入。
• 只读引用（Read-Only Reference）： 服务通过远程调用或事件订阅获取其他服务的数据副本，本地缓存仅为“近端缓存”，必须依赖失效通知或TTL刷新。

下图展示了两个服务之间的数据所有权关系及其对应的缓存域划分：

4.3 缓存域的定义与边界

缓存域（Cache Domain）是指一组数据在缓存层面具有相同生命周期、失效策略和一致性要求的逻辑范围。缓存域与服务边界的关系可以归纳为以下三种模式：

4.4 服务边界与缓存域对齐策略

在实际架构设计中，服务边界与缓存域的对齐需要遵循以下步骤：

1. 识别业务聚合根： 使用DDD的聚合根（Aggregate Root）作为服务的最小数据单元，聚合根内的所有实体共享同一个缓存域。
2. 绘制数据所有权矩阵： 明确每个数据项属于哪个服务的写主范围，标记出跨服务引用的数据。
3. 定义缓存域边界： 为每个写主服务划定本地缓存域，为跨服务引用划定近端缓存域并配置失效策略。
4. 设计缓存失效协议： 基于事件驱动或版本号机制，确保写主数据变更后，所有近端缓存域能及时收到失效通知。

4.5 数据所有权与缓存域的关系矩阵

下表从数据所有权的角度，总结了不同缓存域类型下的操作权限和一致性保障机制：

通过上述矩阵，架构师可以快速判断某个缓存操作是否合法，以及当前缓存域的一致性等级是否满足业务需求。

4.6 边界划分对缓存一致性的实际影响

服务边界划分不当会直接导致缓存一致性问题的恶化。以下是一个典型的反例：

// 反例：服务边界模糊导致缓存穿透
// 服务A（订单服务）直接读取服务B（用户服务）的数据库
// 服务A本地缓存了用户信息，但无法感知用户信息的变更

// 服务A的缓存读取逻辑（错误做法）
public UserInfo getUserInfo(Long userId) {
    UserInfo cached = localCache.get(userId);
    if (cached != null) {
        return cached;
    }
    // 直接查询服务B的数据库（违反数据所有权）
    UserInfo user = userServiceDb.queryById(userId);
    localCache.put(userId, user, 300); // TTL 5分钟
    return user;
}

// 服务B更新用户信息后，服务A的缓存仍然返回旧数据
// 导致订单展示的用户信息与用户服务不一致