DDD中实体与聚合根ID生成方案探讨

针对你提到的DDD场景中自增整数主键的生成矛盾，这里给出几个务实的解决思路，避开你列举的方案弊端：

一、批量预取ID段的领域服务 #

这是对“每次查询数据库取ID”方案的优化，解决性能和领域层依赖问题：

• 实现一个IncrementalIdGenerator领域服务，内部维护一段预取的ID范围（比如一次性从数据库获取100个连续ID）；
• 每次创建实体时，直接从该服务分配一个可用ID，当当前段的ID用完时，自动向数据库请求下一段；
• 数据库侧可以用专门的序列表（比如id_sequences，存储每个聚合根类型的当前最大ID），或者利用MySQL的SHOW TABLE STATUS读取当前自增值并更新，确保ID段不重复。

这种方式既保证实体创建时就有合法的唯一ID，又大幅减少数据库往返次数，领域层只依赖这个服务的抽象接口，不会耦合数据库细节。

二、工厂+仓库协作生成ID #

你的疑问“实体或聚合根不应即时创建，而应始终由仓库提供？”方向是对的，具体落地可以这样做：

• 定义聚合根工厂类，工厂的创建方法需要传入一个合法的ID；
• 仓库实现类负责与数据库交互获取ID（同样可以用批量预取优化），对外暴露NextId()方法；
• 应用层创建聚合根时，先调用仓库的NextId()拿到ID，再传给工厂构建完整的聚合根实例。

这种方式符合DDD的依赖倒置原则，领域层只依赖仓库和工厂的抽象，不会直接操作数据库，同时保证实体从诞生起就有有效标识。

三、临时标识过渡（不推荐，仅作备选） #

如果上述方案暂时无法落地，可以用临时标识过渡：

• 实体创建时先分配一个内存级的唯一标识（比如内存自增ID、临时UUID），用于内存中区分实体；
• 当持久化到数据库后，再将数据库生成的自增ID替换掉临时标识。

但要注意：临时标识只能在内存上下文使用，不能用于跨域、持久化相关的业务逻辑，否则会出现标识不一致的问题，仅适合短期过渡场景。

对原有方案弊端的补充说明 #

• 方案1（null/默认ID）：确实违反DDD实体的核心特性——实体在整个生命周期内必须有稳定的唯一标识，空值或默认值会导致业务逻辑中出现大量无效判断，极易引发bug，完全不推荐；
• 方案2（单次查询取ID）：高并发场景下会产生频繁的数据库交互，且领域层直接耦合数据库操作，破坏领域层的纯净性，必须用批量预取优化；
• 方案3（改为GUID）：如果当初选择自增ID是出于索引性能、业务有序性等需求，完全没必要为了ID生成修改主键类型，前面的方案可以完美解决矛盾。

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