4. 服务边界设计原则：领域驱动设计（DDD）在可观测性系统中的应用

在多租户可观测性系统中，服务边界划分的合理性直接决定了系统的可维护性、扩展性以及租户隔离的复杂度。领域驱动设计（DDD）提供了一套成熟的方法论，帮助架构师从业务领域出发，识别核心概念并划定有界上下文（Bounded Context），从而避免“大泥球”架构。

4.1 为什么可观测性系统需要 DDD？

传统的可观测性系统往往将指标、日志、链路追踪视为统一的数据管道，导致服务边界模糊、数据模型耦合严重。在多租户场景下，这种耦合会引发以下问题：

• 租户隔离逻辑散落：租户 ID 在多个服务间传递，缺乏统一的上下文边界。
• 数据模型膨胀：指标、日志、事件共用同一存储模型，字段含义随业务迭代而混乱。
• 团队协作冲突：多个团队修改同一代码库，频繁产生合并冲突和回归缺陷。

DDD 通过有界上下文将领域划分为独立的子域，每个子域拥有自己的通用语言（Ubiquitous Language）和数据模型，从而在架构层面实现解耦。

4.2 可观测性领域的核心子域与有界上下文

我们将可观测性系统拆解为以下核心子域，每个子域对应一个独立的有界上下文：

每个上下文内部维护独立的数据库、独立的 API 网关入口，并通过领域事件进行异步通信。

4.3 有界上下文划分的实战原则

在划分有界上下文时，我们遵循以下四条原则：

1. 数据所有权原则：每个上下文拥有且仅拥有其核心实体的写权限。例如，MetricSeries 的写入只能由指标上下文完成，日志上下文只能通过事件订阅读取指标摘要。
2. 变化频率原则：将变化频率不同的模型分离。指标聚合逻辑可能每周迭代，而租户管理模型可能每月才变更一次，二者不应放在同一上下文中。
3. 租户隔离原则：每个上下文必须显式声明其支持的租户隔离粒度。例如，指标上下文按租户分片存储，而租户管理上下文使用共享数据库但通过行级权限控制。
4. 团队规模原则：一个上下文应由一个 2-8 人的团队全权负责，避免跨团队协调成为瓶颈。

4.4 有界上下文之间的协作模式

有界上下文之间并非完全隔离，它们需要通过定义良好的接口进行协作。以下是三种常见的协作模式：

• 客户方/供应方模式：日志上下文作为供应方，提供日志检索 API；告警上下文作为客户方，调用该 API 获取日志样本用于告警详情展示。
• 发布/订阅模式：指标上下文发布 MetricThresholdBreached 事件，事件上下文订阅后触发告警通知流程。
• 共享内核模式：多个上下文共享一个轻量级的 TenantId 值对象，但禁止共享复杂的业务实体。

下图展示了五个有界上下文之间的典型协作关系：

4.5 从有界上下文到微服务

有界上下文是逻辑边界，微服务是部署边界。在将 DDD 映射到微服务架构时，我们遵循以下映射规则：

4.6 实战案例：划分“指标上下文”的有界上下文

以指标上下文为例，我们进一步展示如何在其内部应用 DDD 进行子域划分：

// 指标上下文内部的聚合根示例
public class MetricSeries {
    private TenantId tenantId;
    private MetricName metricName;
    private Map<String, String> tags;
    private List<TimeBucket> buckets;

    // 业务方法：追加数据点
    public void appendDataPoint(DataPoint point) {
        // 校验租户 ID 一致性
        if (!point.getTenantId().equals(this.tenantId)) {
            throw new DomainException("租户 ID 不匹配");
        }
        // 找到对应的时间桶并追加
        TimeBucket bucket = findOrCreateBucket(point.getTimestamp());
        bucket.addValue(point.getValue());
    }
}

// 仓储接口，自动注入租户过滤
public interface MetricSeriesRepository {
    MetricSeries findByTenantAndName(TenantId tenantId, MetricName name);
    void save(MetricSeries series);
}

上述代码中，TenantId 作为值对象贯穿整个聚合根，确保所有操作都在租户边界内执行。仓储实现层会自动在 SQL 查询中添加 WHERE tenant_id = ? 条件，从数据访问层面强制隔离。