DDD架构下领域事件中合理嵌入UserId的技术问询

这是个非常典型的DDD落地问题，我之前在做类似的文档审批系统时也纠结过这个点，给你分享几个经过实践验证的可行思路：

方案1：使用Ambient Context（全局上下文）传递用户信息 #

这种方式可以让领域层在不需要显式传参的情况下获取当前用户ID，核心是通过一个线程安全的上下文容器，在请求入口（比如WebApi的管道）注入当前用户信息，然后领域层直接从容器中读取。

实现示例： #

首先定义一个线程安全的用户上下文类（可以放在基础设施层或者共享工具类里）：

public static class CurrentUserContext
{
    // 使用AsyncLocal保证异步场景下的线程安全
    private static readonly AsyncLocal<Guid?> _currentUserId = new AsyncLocal<Guid?>();
    
    public static Guid? UserId => _currentUserId.Value;
    
    // 供上层设置用户ID的方法
    public static void SetCurrentUserId(Guid userId)
    {
        _currentUserId.Value = userId;
    }
}

然后在WebApi的请求管道中设置用户信息：

// 在Program.cs的中间件里添加
app.Use(async (context, next) =>
{
    var userIdClaim = context.User.FindFirst(ClaimTypes.NameIdentifier);
    if (userIdClaim != null && Guid.TryParse(userIdClaim.Value, out var userId))
    {
        CurrentUserContext.SetCurrentUserId(userId);
    }
    
    await next();
});

最后在领域事件中直接使用：

public class DocumentApproved : IDomainEvent 
{ 
    public DocumentApproved(Document document) 
    { 
        DocumentId = document.Id; 
        Timestamp = DateTime.UtcNow; // 建议用UTC时间避免时区问题
        UserId = CurrentUserContext.UserId ?? throw new InvalidOperationException("无法获取当前操作用户");
    } 
    
    public Guid Id { get; } = Guid.NewGuid();
    public Guid UserId { get; } 
    public DateTime Timestamp { get; } 
    public Guid DocumentId { get; } 
}

优点：领域实体方法签名完全干净，不需要额外传参；缺点：领域层依赖了全局上下文，测试时需要手动设置上下文信息（不过这个成本很低）。

方案2：在应用层补充领域事件的用户信息 #

这种思路是让领域层只关注核心业务逻辑，用户ID这类“操作元数据”由应用层负责补充，保持领域层的纯净性。

实现示例： #

首先定义一个标记接口，让需要用户ID的领域事件实现它：

public interface IHasUserId : IDomainEvent
{
    Guid UserId { get; set; }
}

修改领域事件类：

public class DocumentApproved : IHasUserId 
{ 
    public DocumentApproved(Document document) 
    { 
        DocumentId = document.Id; 
        Timestamp = DateTime.UtcNow;
        Id = Guid.NewGuid();
    } 
    
    public Guid Id { get; }
    public Guid UserId { get; set; } // 改为可设置属性
    public DateTime Timestamp { get; } 
    public Guid DocumentId { get; } 
}

然后在应用层的命令处理程序中，获取当前用户ID并补充到事件里：

public class ApproveDocumentHandler : IRequestHandler<ApproveDocumentCommand>
{
    private readonly IDocumentRepository _documentRepo;
    private readonly ICurrentUserService _currentUserService; // 注入获取当前用户的服务
    
    public ApproveDocumentHandler(IDocumentRepository documentRepo, ICurrentUserService currentUserService)
    {
        _documentRepo = documentRepo;
        _currentUserService = currentUserService;
    }

    public async Task<Unit> Handle(ApproveDocumentCommand request, CancellationToken cancellationToken)
    {
        var document = await _documentRepo.GetByIdAsync(request.DocumentId);
        document.Approve(); // 领域方法依然不需要传用户ID
        
        // 给所有需要用户ID的事件补充信息
        var currentUserId = _currentUserService.GetCurrentUserId();
        foreach (var domainEvent in document.DomainEvents.OfType<IHasUserId>())
        {
            domainEvent.UserId = currentUserId;
        }
        
        await _documentRepo.SaveAsync(document);
        // 发布领域事件...
        return Unit.Value;
    }
}

优点：领域层完全不依赖外部上下文，保持纯净；缺点：需要额外定义标记接口，应用层需要做一次事件的遍历处理（但这个逻辑可以封装成通用方法，不用每个处理程序都写）。

方案3：将用户ID作为领域方法的显式参数（可选） #

如果你认为“谁执行了审批”是领域逻辑的一部分（比如某些审批规则依赖审批人角色），那把UserId作为领域方法的参数其实并不冗余，反而让领域方法的语义更完整：

实现示例： #

// 领域实体方法
public void Approve(Guid approverUserId)
{
    // 这里还可以加领域规则校验，比如审批人是否有权限（如果权限属于领域逻辑的话）
    if (!_allowedApproverIds.Contains(approverUserId))
    {
        throw new InvalidOperationException("该用户无审批权限");
    }
    
    State = State.Approve(this);
    ApprovalRevision.Next();
    Events.Add(new DocumentApproved(this, approverUserId));
}

// 领域事件
public class DocumentApproved : IDomainEvent 
{ 
    public DocumentApproved(Document document, Guid approverUserId) 
    { 
        DocumentId = document.Id; 
        Timestamp = DateTime.UtcNow;
        UserId = approverUserId;
        Id = Guid.NewGuid();
    } 
    
    // 省略属性...
}

优点：领域方法语义明确，没有隐式依赖，测试时参数传递清晰；缺点：如果很多领域操作都需要UserId，会导致方法签名重复（可以封装一个OperationMetadata类来统一传递UserId、操作时间等元数据）。

总结推荐 #

• 如果你想最大化保持领域方法的简洁性，优先选方案1；
• 如果你想严格保持领域层的纯净性，不依赖任何外部上下文，优先选方案2；
• 如果用户ID本身就是领域规则的一部分，那方案3会更合适。

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