使用DDD聚合与预生成ID时遭遇AggregateUpdateConcurrencyException的解决方法

你遇到的错误本质是EF Core误将预生成GUID的新增Visit实体判定为已存在的实体，执行更新操作而非插入，导致数据库中找不到对应行而抛出异常。以下是针对性的解决步骤：

1. 明确配置EF Core实体ID生成策略 #

必须在Visit实体的EF配置中，明确告知框架ID由应用程序预生成，而非数据库自动生成。这是核心解决方案：

public class VisitConfiguration : IEntityTypeConfiguration<Visit>
{
    public void Configure(EntityTypeBuilder<Visit> builder)
    {
        builder.HasKey(v => v.Id);
        // 关键：禁用数据库自动生成ID，指定ID由应用提供
        builder.Property(v => v.Id).ValueGeneratedNever();
        
        // 其他字段配置（如就诊时间、类型等）
    }
}

将该配置注册到DbContext的OnModelCreating方法中：

protected override void OnModelCreating(ModelBuilder modelBuilder)
{
    modelBuilder.ApplyConfiguration(new VisitConfiguration());
    // 其他实体配置...
}

2. 确保聚合根处于EF跟踪状态 #

你的Repository的GetByIdAsync方法必须返回被EF Core跟踪的Patient实体，否则框架无法感知新增的Visit子实体：

public async Task<Patient> GetByIdAsync(Guid patientId, CancellationToken cancellationToken)
{
    // 不要使用AsNoTracking()，确保实体处于跟踪状态
    return await _dbContext.Patients
        // 如果需要立即加载Visit集合（可选，根据你的业务需求）
        // .Include(p => p.Visits)
        .FirstOrDefaultAsync(p => p.Id == patientId, cancellationToken);
}

3. 检查EF Core拦截器的状态影响 #

你提到用EF拦截器将ID发送到缓存，需确保拦截器没有错误修改实体的跟踪状态：

• 不要将新增的Visit实体的EntityState从Added改为Modified或Unchanged
• 拦截器仅处理ID的缓存同步，不干扰EF的实体状态管理

4. 多DbContext场景的额外注意 #

如果你的模块化单体架构中，Patient和Visit分属不同DbContext：

• 需确保Visit实体被单独添加到对应的DbContext中（因为跨DbContext的聚合根无法通过一次SaveChanges完成持久化）
• 调整Repository设计：通过Patient聚合根的方法生成Visit后，调用VisitRepository的Add方法，再分别保存两个DbContext的变更（需保证事务一致性）

验证实体状态（调试用） #

在调用SaveChangesAsync前，可临时添加代码验证Visit的状态是否为Added：

var visitEntries = _dbContext.ChangeTracker.Entries<Visit>();
foreach (var entry in visitEntries)
{
    Debug.WriteLine($"Visit ID: {entry.Entity.Id}, State: {entry.State}");
    // 正常新增的Visit应该显示State: Added
}

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