DDD实践：成员激活授权不变量的实现疑问

作为DDD的实践者，我来帮你拆解这个问题，一步步理清思路：

一、不变量2的最优实现方式：封装到领域实体中 #

不变量2「章节管理员仅能激活非活跃成员」本质是成员状态变更的业务规则，按照DDD的封装原则，这类规则应该内聚到Member实体内部，而不是放在应用服务或外部服务中。

你可以在Member类中实现Activate()方法，在方法内部先校验当前状态：

public class Member
{
    public MemberStatus Status { get; private set; }

    public void Activate()
    {
        if (Status == MemberStatus.Active)
        {
            throw new DomainException("该成员已处于活跃状态，无法重复激活");
        }
        // 执行激活逻辑，比如更新状态为Active
        Status = MemberStatus.Active;
    }
}

这样一来，无论哪个层调用Activate()方法，都会触发这个校验，从根源上保证规则的一致性，避免在多个地方重复实现校验逻辑，也减少了规则被遗漏的风险。

你的命令处理程序逻辑可以保持不变：加载成员 → 调用Activate() → 持久化。此时不变量2的校验会自动在实体内部执行。

二、关于两个疑问的解答 #

1. 是否应将Identity域的认证服务下沉至领域层？ #

绝对不应该。领域层的核心是业务规则和领域概念，必须保持纯净，不能依赖外部的认证框架（比如.NET Identity）或基础设施服务。

正确的做法是：

• 在应用服务层获取当前用户的身份上下文（比如角色、所属章节ID）——这一步可以通过应用层的身份服务实现，不需要直接依赖.NET Identity，你可以封装一个IUserContext接口，在基础设施层用.NET Identity实现它。
• 将身份上下文作为参数传递给领域服务或实体方法，由领域层基于这些上下文执行授权规则（比如不变量1和3）。

举个例子，应用服务的代码可以是这样：

public class MemberApplicationService
{
    private readonly IMemberRepository _memberRepository;
    private readonly IUserContext _userContext;
    private readonly IMemberAuthorizationService _memberAuthorizationService;

    public MemberApplicationService(IMemberRepository memberRepository, IUserContext userContext, IMemberAuthorizationService memberAuthorizationService)
    {
        _memberRepository = memberRepository;
        _userContext = userContext;
        _memberAuthorizationService = memberAuthorizationService;
    }

    public async Task ActivateMemberAsync(Guid memberId)
    {
        // 获取当前用户的身份上下文
        var currentUser = await _userContext.GetCurrentUserAsync();
        // 加载要激活的成员
        var member = await _memberRepository.GetByIdAsync(memberId);
        
        // 领域层处理授权规则（不变量1、3）
        _memberAuthorizationService.EnsureCanActivateMember(currentUser, member);
        
        // 触发实体内部的状态变更规则（不变量2）
        member.Activate();
        
        // 持久化
        await _memberRepository.SaveAsync(member);
    }
}

2. 在应用服务中实现不变量2，两次加载成员是否合理？ #

首先，这种做法本身就不符合DDD的职责划分——业务规则不该放在应用服务里。退一步说，两次加载成员不仅会带来不必要的性能开销，还会引入并发风险：第一次加载后到第二次加载前，成员的状态可能被其他请求修改，导致校验逻辑基于过时的数据执行。

如果你真的出于某种原因要在应用服务层做校验，也应该只加载一次成员，直接基于当前加载的实例检查状态：

// 不推荐，但如果要这么做，只加载一次
var member = await _memberRepository.GetByIdAsync(memberId);
if (member.Status == MemberStatus.Active)
{
    throw new ApplicationException("成员已活跃");
}
member.Activate();
await _memberRepository.SaveAsync(member);

但还是强烈建议把状态校验逻辑放在Member实体内部，这才是DDD的正确实践。

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