DDD架构下数据库生成ID的处理方案及性能优化咨询

一、避免领域层依赖数据库ID生成的核心方案 #

1. 应用层预生成业务友好的ID #

不要依赖数据库生成ID，而是在应用层（而非领域层）提前生成符合要求的ID，再传入聚合根构造函数。这样领域服务完全不需要调用SaveChanges这类数据库操作，保持领域层的纯净性。

2. 采用有序ID生成策略（解决UUID索引性能问题） #

针对无序UUID的索引性能缺陷，用以下几种有序ID方案替代：

• 雪花算法（Snowflake）：生成64位整数ID，包含时间戳、机器标识、序列号，保证全局唯一且递增，数据库索引性能和自增ID接近。实现简单，多数语言都有成熟工具库，无需依赖数据库。
• UUIDv7：基于时间戳的UUID版本，前12位为毫秒级时间戳，天然有序，既保留UUID的分布式特性，又解决了无序UUID的索引碎片问题，现代主流数据库已支持对其高效索引。
• 数据库序列预取：如果必须用数据库生成ID，可在应用层提前从数据库序列（如PostgreSQL的nextval）获取一批ID缓存，再分配给聚合根。领域层拿到预先生成的ID后，无需先保存聚合根就能传递ID，避免领域服务耦合数据库操作。

二、重构依赖数据库ID的业务逻辑 #

如果遇到必须先保存A聚合根再传递ID给B聚合根的场景，不要在领域服务里直接调用数据库操作，而是调整业务流程：

• 把“生成A的ID并传递给B”的逻辑放到应用层：应用层先预生成A的ID，创建A聚合根，再用这个ID创建B聚合根，最后一次性批量保存所有聚合根。
• 若业务规则要求A必须先持久化才能创建B，可通过领域事件解耦：A聚合根保存后触发ACreated事件，事件处理器在应用层接收事件后，再创建B聚合根并关联A的ID，领域服务仅负责发布事件，不依赖数据库操作。

三、兼容已有数据库的过渡方案 #

如果已有数据库使用自增ID，不想大规模改动：

• 在应用层新增业务ID字段（用雪花算法或UUIDv7生成），作为聚合根的唯一标识在领域层使用，数据库自增ID仅作为存储层主键，领域层不直接依赖它。
• 调整ORM映射：让ORM将业务ID作为领域对象的标识，自增ID作为内部存储字段，对领域层透明。

内容的提问来源于stack exchange，提问作者user7263939