3. 合规边界定义：GDPR、HIPAA、PCI-DSS 对后端数据建模的影响

在领域驱动设计（DDD）中，合规边界是限界上下文（Bounded Context）的一种特殊形式。它要求数据模型不仅满足业务逻辑，还必须满足法律与行业监管的强制性约束。本章聚焦三大主流合规框架——GDPR（欧盟通用数据保护条例）、HIPAA（美国健康保险携带和责任法案）和 PCI-DSS（支付卡行业数据安全标准），分析它们如何影响实体设计、值对象定义、聚合边界以及数据持久化策略。

3.1 三大合规框架的核心数据约束对比

下表从数据分类、存储限制、访问控制和删除/匿名化四个维度，对比 GDPR、HIPAA、PCI-DSS 对后端数据建模的直接影响。

3.2 GDPR：数据最小化与“被遗忘权”的建模策略

GDPR 对领域模型最深远的影响是数据最小化和可删除性。在 DDD 中，这意味着：

• 实体设计：只保留业务必需的属性。例如，用户实体不应包含“IP 地址”或“设备指纹”等非核心字段，除非有明确的法律依据。
• 值对象封装：将敏感数据（如身份证号、生物特征）封装为独立值对象，并附加“处理目的”和“同意 ID”元数据。
• 聚合边界：将“同意记录”作为独立的聚合根，与用户实体通过 ID 关联，而非直接嵌入用户聚合。

// 示例：GDPR 合规的用户聚合设计（伪代码）
public class User : AggregateRoot {
    public UserId Id { get; private set; }
    public Email Email { get; private set; }          // 值对象
    public HashedPassword Password { get; private set; } // 值对象
    // 不直接存储 IP、设备指纹等非必要字段
}

public class Consent : AggregateRoot {
    public ConsentId Id { get; private set; }
    public UserId UserId { get; private set; }
    public ProcessingPurpose Purpose { get; private set; } // 值对象
    public DateTime GrantedAt { get; private set; }
    public DateTime? RevokedAt { get; private set; }
    // 撤销时触发删除关联数据
}

3.3 HIPAA：PHI 保护与审计追踪的聚合设计

HIPAA 要求对受保护健康信息（PHI）实施最小必要访问，并记录所有访问行为。在领域模型中，这体现为：

• PHI 值对象：所有 PHI 字段（如诊断代码、检查结果）必须封装为值对象，且序列化时自动加密。
• 审计日志聚合：每次对 PHI 的读取或修改，都必须在同一个事务中生成审计记录。审计日志应作为领域事件的副产品，而非事后追加。
• 聚合拆分：将“患者基本信息”与“临床 PHI 数据”拆分为不同聚合，通过患者 ID 关联，以限制非授权上下文的访问范围。

// 示例：HIPAA 合规的审计日志生成（领域事件驱动）
public class MedicalRecord : AggregateRoot {
    public RecordId Id { get; private set; }
    public PatientId PatientId { get; private set; }
    public PhiValueObject Diagnosis { get; private set; } // 加密存储

    public void UpdateDiagnosis(PhiValueObject newDiagnosis, string userId) {
        var oldDiagnosis = this.Diagnosis;
        this.Diagnosis = newDiagnosis;
        // 触发领域事件，由事件处理器生成审计日志
        AddDomainEvent(new DiagnosisUpdatedEvent(this.Id, oldDiagnosis, newDiagnosis, userId, DateTime.UtcNow));
    }
}

3.4 PCI-DSS：持卡人数据的令牌化与隔离边界

PCI-DSS 对后端建模最严格的约束是：禁止存储敏感认证数据（SAD），且主账号（PAN）必须加密或令牌化。在 DDD 中，这要求：

• 令牌化值对象：PAN 字段在领域模型中只能以令牌（Token）形式存在。原始 PAN 必须由外部令牌服务（如 Vault）管理。
• 严格限界上下文：支付相关数据必须隔离在独立的“支付上下文”中，禁止与用户上下文、订单上下文共享数据库。
• 禁止存储字段：CVV/CVC、完整磁条数据、PIN 码等字段，在领域模型中根本不应出现。如果业务需要验证，应通过外部服务实时校验。

// 示例：PCI-DSS 合规的支付聚合设计
public class Payment : AggregateRoot {
    public PaymentId Id { get; private set; }
    public OrderId OrderId { get; private set; }
    public TokenizedPan CardToken { get; private set; } // 令牌值对象
    public Money Amount { get; private set; }
    // 没有 CVV、没有原始 PAN、没有磁条数据
}

// 令牌值对象：只存储引用，不存储原始值
public class TokenizedPan : ValueObject {
    public string Token { get; }
    public string LastFourDigits { get; } // 仅用于展示
    // 构造函数确保 Token 不为空
}

3.5 合规边界对数据建模的综合影响（SVG 架构图）

下图展示了一个多合规框架共存的后端领域模型架构。左侧是业务限界上下文，右侧是合规约束层，中间通过合规适配器进行数据转换与隔离。

3.6 合规边界建模的常见陷阱与最佳实践