DDD：如何处理“唯一性”业务逻辑

背景

唯一性约束是一个经常出现的业务逻辑，刚开始我觉得非常简单，不过深入考虑后，发现实现起来还不是那么简单，下面就让我们分析一下。

两种场景下的唯一性约束

第一种场景：聚合根的某个属性的唯一性约束

示例：用户的用户名必须唯一。

第一种实现思路：后验证+不用数据库索引，在插入用户名和修改用户名之后执行一次验证，这个验证逻辑执行的事务隔离级别必须处于“读未提交”级别。

public volid Insert(User user)
{
    using(var ts1 = new TransactionScope("读已提交"))
    {
        DoInsert(user);
        using(var ts2 = new TransactionScope("读未提交"))
        {
            //如果违背约束，抛出异常。
        }
        ts1.Complete();
    }
}

 第二种实现思路：前验证+不用数据库索引，在插入用户名和修改用户名之前执行一次验证，整个事务运行在“串行化”隔离级别。

public volid Insert(User user)
{
    using(var ts = new TransactionScope("串行化"))
    {            
        //如果违背约束，抛出异常。
        DoInsert(user);
        ts.Complete();
    }
}

 第三种实现思路：前验证+数据库索引，在插入用户名和修改用户名之前执行一次验证，整个事务运行在“读已提交”隔离级别。

public volid Insert(User user)
 {
     using(var ts = new TransactionScope("读已提交"))
     {            
         //如果违背约束，抛出异常。
         DoInsert(user);
         ts.Complete();
     }
 }

 第四实现思路种：内存锁。

有朋友会想，为啥不直接用数据库索引呢？失败了就跑出异常，因为我们需要收集到友好的异常信息显示给UI，所以才需要在程序里判定唯一性，然后抛出友好的异常信息。

总体来说我觉得第三种思路在现实中比较方便。

第二种场景：聚合内某个实体的属性的唯一性约束

示例：订单的订单项的产品必须唯一。

第一种实现思路：聚合根的乐观锁+聚合自身必须保证这种约束。

我觉得这个场景下只有这一种实现是比较合理的，就不介绍其他思路了。

备注

在健身房仓促写就，大家多提意见。