3. 数据模型与领域建模：对象存储的领域模型设计、实体关系图、聚合根设计、值对象与实体对象的划分
在对象存储架构中，领域模型是连接业务需求与技术实现的桥梁。本章将围绕对象存储的核心业务逻辑，运用领域驱动设计（DDD）的方法论，系统性地构建数据模型，明确实体与值对象的边界，并设计聚合根以确保数据一致性与性能。
3.1 对象存储核心领域概念
对象存储的领域模型围绕三个核心概念展开：桶（Bucket）、对象（Object）和元数据（Metadata）。桶是对象的容器，对象是存储的基本单元，元数据则描述对象的属性。此外，还需要考虑用户（User）、访问策略（Policy）和存储池（StoragePool）等支撑实体。
| 领域概念 | 类型 | 核心职责 | 生命周期 |
|---|---|---|---|
| User | 实体（Entity） | 身份认证、配额管理、API密钥 | 长期存在，由管理员创建/删除 |
| Bucket | 聚合根（Aggregate Root） | 对象容器、访问控制、版本控制、跨区域复制 | 由用户创建，可删除 |
| Object | 实体（Entity） | 数据存储、元数据关联、分片管理 | 由用户上传/删除，版本化 |
| ObjectMetadata | 值对象（Value Object） | Content-Type、ETag、自定义标签、创建时间 | 随对象创建而生成，不可变 |
| AccessPolicy | 值对象（Value Object） | IAM策略、ACL、预签名URL规则 | 可被替换，不可单独修改 |
| StoragePool | 实体（Entity） | 物理存储资源抽象、故障域、容量管理 | 由运维系统管理 |
领域建模原则：在对象存储中，Bucket 作为聚合根承担了事务一致性的边界。所有对对象的操作（上传、删除、列举）都必须通过 Bucket 进行，这保证了跨多个对象的操作不会破坏业务规则（如配额检查、跨区域复制同步）。
3.2 实体关系图（ERD）
下图展示了对象存储核心领域模型的实体关系。注意 Bucket 作为聚合根，与 Object 之间存在一对多的强关联；Object 与 ObjectMetadata 之间是组合关系，元数据不能脱离对象独立存在。
设计要点：在 ERD 中，ObjectMetadata 被建模为值对象，因为它的所有属性（Content-Type、ETag、自定义标签）共同描述对象的某个快照状态。如果元数据发生变化，通常意味着创建了一个新的对象版本，而不是修改现有元数据。这种不可变性简化了缓存和并发控制。
3.3 聚合根设计：以 Bucket 为中心
聚合根是领域模型中保证数据一致性的核心。在对象存储中，Bucket 是最自然的聚合根选择。所有对对象的操作都必须通过 Bucket 进行，这确保了以下业务规则始终得到满足：
- 配额约束：上传对象前，Bucket 必须检查所属 User 的总容量配额。
- 版本一致性：当 Bucket 开启版本控制时，对象的每次覆盖操作都会生成新版本，Bucket 负责维护版本链。
- 跨区域复制：Bucket 的复制策略变更需要同步到所有关联的 Object 上传路径。
- 访问控制：Bucket 级别的 IAM 策略必须优先于对象级别的 ACL。
以下代码片段展示了 Bucket 聚合根的核心接口设计：
// Bucket 作为聚合根，封装了所有对象操作的一致性边界
public class Bucket {
private BucketId bucketId;
private UserId ownerId;
private BucketConfiguration config; // 值对象，包含版本控制、复制策略等
private List<Object> objects; // 实体集合，通过仓储延迟加载
// 上传对象：先校验配额，再创建对象版本
public ObjectUploadResult uploadObject(
ObjectKey key,
InputStream data,
ObjectMetadata metadata
) {
// 1. 校验配额（调用 User 领域服务）
if (!quotaService.checkQuota(ownerId, data.available())) {
throw new QuotaExceededException();
}
// 2. 根据版本控制策略决定是否创建新版本
if (config.isVersioningEnabled()) {
return createNewVersion(key, data, metadata);
} else {
return overwriteObject(key, data, metadata);
}
}
// 删除对象：标记删除或物理删除，取决于配置
public void deleteObject(ObjectKey key) {
// 聚合根内保证删除操作与复制策略的原子性
Object obj = findObjectByKey(key);
if (config.isCrossRegionReplicationEnabled()) {
replicationService.scheduleDelete(obj);
}
objects.remove(obj);
}
}
常见设计误区：不要将 Object 本身设计为聚合根。如果每个 Object 都是聚合根，那么跨对象的批量操作（如列举 Bucket 内所有对象、批量删除）将无法保证一致性。此外，Object 的生命周期完全由 Bucket 管理，脱离 Bucket 的 Object 没有业务意义。
3.4 实体对象与值对象的划分标准
在对象存储领域模型中，正确区分实体和值对象直接影响系统的可维护性和性能。以下是具体的划分标准与示例：
| 判断维度 | 实体（Entity） | 值对象（Value Object） | 对象存储示例 |
|---|---|---|---|
| 唯一标识 | 必须有（如 UUID、自增 ID） | 无，通过属性值相等判断 | Object 有 objectId；ObjectMetadata 无独立 ID |
| 可变性 | 可变（属性可更新） | 不可变（替换而非修改） | Object 的 storageClass 可变更；Metadata 的 etag 不可变 |
| 生命周期 | 独立生命周期，可被追踪 | 依附于实体，随实体创建/销毁 | Bucket 可独立删除；AccessPolicy 随 Bucket 删除而消失 |
| 相等性判断 | 通过 ID 判断 | 通过所有属性值判断 | 两个 Object 即使内容相同，ID 不同则不同；两个 Metadata 属性全等则相等 |
| 共享与引用 | 可被多个聚合根引用 | 通常不共享，或共享时复制 | StoragePool 可被多个 Bucket 引用；ObjectMetadata 不跨对象共享 |
3.5 聚合内部一致性策略
为了在分布式环境下保持聚合内部的一致性，对象存储通常采用以下策略：
- 事务边界最小化：一次用户请求（如上传对象）只影响一个 Bucket 聚合，避免跨聚合事务。
- 最终一致性补偿：对于跨区域复制等需要跨聚合的操作，使用 Saga 模式或事件溯源来保证最终一致性。
- 乐观并发控制：通过对象的版本号（ETag）或 Bucket 的修订号实现 CAS（Compare-And-Swap）操作。
下图展示了对象上传操作在聚合边界内的一致性流程：
性能优化提示：在聚合根内部，尽量将值对象（如 ObjectMetadata）与实体（如 Object）的存储分离。元数据通常较小且访问频繁，可以放在缓存层（如 Redis）中；而对象数据体较大，应直接写入分布式存储集群。这种分离既减少了聚合根的内存占用，又提升了元数据的查询性能。
3.6 领域事件与数据同步
对象存储的领域模型还需要考虑跨聚合的异步通信。当 Bucket 聚合根内部发生状态变更时（如对象上传、删除），会发布领域事件，供其他限界上下文消费：
- ObjectUploadedEvent：触发索引更新、跨区域复制、CDN 缓存刷新。
- ObjectDeletedEvent：触发垃圾回收、存储空间释放、备份同步。
- BucketConfigurationChangedEvent：触发所有关联对象的策略重新评估。
通过领域事件，对象存储系统可以在保持聚合根强一致性的同时，实现整个系统的最终一致性和高可用性。