dfdffdg8l00002001

[Abp vNext 源码分析] - 5. DDD 的领域层支持(仓储、实体、值对象)

一、简要介绍

ABP vNext 框架本身就是围绕着 DDD 理念进行设计的，所以在 DDD 里面我们能够见到的实体、仓储、值对象、领域服务，ABP vNext 框架都为我们进行了实现，这些基础设施都存放在 Volo.Abp.Ddd.Domain 项目当中。

本篇文章将会侧重于理论讲解，但也只是一个抛砖引玉的作用，关于 DDD 相关的知识可以阅读 Eric Evans 所编写的《领域驱动设计：软件核心复杂性应对之道》。

PS：

该书也是目前我正在阅读的 DDD 理论书籍，因为基于 DDD 理论，我们能够精准地划分微服务的业务边界，为后续微服务架构的可扩展性提供坚实的基础。

二、源码分析

Volo.Abp.Ddd.Domain 分为 Volo 和 Microsoft 两个文件夹，在 Microsoft 文件夹当中主要是针对仓储和实体进行自动注入。

2.1 实体 (Entity)

2.1.1 基本概念

只要用过 EF Core 框架的人，基本都知道什么是实体。不过很多人就跟我一样，只是将实体作为数据库表在 C# 语言当中的另一种展现方式，认为它跟普通的对象没什么不一样。

PS：虽然每个对象都会有一个内在的 对象引用指针 来作为唯一标识。

在 DDD 的概念当中，通过标识定义的对象被称为实体(Entity)。虽然它们的属性可能因为不同的操作而被改变（多种生命周期），但必须保证一种内在的连续性。为了保证这种内在的连续性，就需要一个有意义并且唯一的属性。

标识是否重要则完全取决于它是否有用，例如有个演唱会订票程序，你可以将座位与观众都当作一个实体处理。那么在分配座位时，每个座位肯定都会有一个唯一的座位号(唯一标识)，可也能拥有其他描述属性(是否是 VIP 座位、价格等...)。

那么座位是否需要唯一标识，是否为一个实体，就取决于不同的入场方式。假如说是一人一票制，并且每张门票上面都有固定的座位号，这个时候座位就是一个实体，因为它需要座位号来区分不同的座位。

另一种方式就是入场卷方式，门票上没有座位号，你想坐哪儿就坐哪儿。这个时候座位号就不需要与门票建立关联，在这种情况下座位就不是一个实体，所以不需要唯一标识。

* 上述例子与描述改编自《领域驱动设计：软件核心复杂性应对之道》的 ENTITY 一节。

2.1.2 如何实现

了解了 DDD 概念里面的实体描述之后，我们就来看一下 ABP vNext 为我们准备了怎样的基础设施。

首先看 Entities 文件夹下关于实体的基础定义，在实体的基础定义类里面，为每个实体定义了唯一标识。并且在某些情况下，我们需要确保 ID 在多个计算机系统之间具有唯一性。

尤其是在多个系统/平台进行对接的时候，如果每个系统针对于 “张三” 这个用户的 ID 不是一致的，都是自己生成 ID ，那么就需要介入一个新的抽象层进行关系映射。

在 IEntity 的默认实现 Entity 中，不仅提供了标识定义，也重写了 Equals() 比较方法和 == != 操作符，用于区别不同实体。它为对象统一定义了一个 TKey 属性，该属性将会作为实体的唯一标识字段。

public override bool Equals(object obj)
{
    // 比较的对象为 NULL 或者对象不是派生自 Entity 都视为不相等。
    if (obj == null || !(obj is Entity))
    {
        return false;
    }

    // 比较的对象与当前对象属于同一个引用，视为相等的。
    if (ReferenceEquals(this, obj))
    {
        return true;
    }

    // 当前比较主要适用于 EF Core，如果任意对象是使用的默认 Id，即临时对象，则其默认 ID 都为负数，视为不相等。
    var other = (Entity)obj;
    if (EntityHelper.HasDefaultId(this) && EntityHelper.HasDefaultId(other))
    {
        return false;
    }

    // 主要判断当前对象与比较对象的类型信息，看他们两个是否属于 IS-A 关系，如果不是，则视为不相等。
    var typeOfThis = GetType().GetTypeInfo();
    var typeOfOther = other.GetType().GetTypeInfo();
    if (!typeOfThis.IsAssignableFrom(typeOfOther) && !typeOfOther.IsAssignableFrom(typeOfThis))
    {
        return false;
    }

    // 如果两个实体他们的租户 Id 不同，也视为不相等。
    if (this is IMultiTenant && other is IMultiTenant &&
        this.As().TenantId != other.As().TenantId)
    {
        return false;
    }

    // 通过泛型的 Equals 方法进行最后的比较。
    return Id.Equals(other.Id);
}

实体本身是支持序列化的，所以特别标注了 [Serializable] 特性。

[Serializable]
public abstract class Entity : Entity, IEntity
{
    // ... 其他代码。
}

针对于某些实体可能是 复合主键 的情况，ABP vNext 则推荐使用 IEntity 和 Entity 进行处理。

/// 
/// 定义一个实体，但它的主键可能不是 “Id”，也有可能是否复合主键。
/// 开发人员应该尽可能使用  来定义实体，以便更好的与其他框架/结构进行集成。
/// 
public interface IEntity
{
    /// 
    /// 返回当前实体的标识数组。
    /// 
    object[] GetKeys();
}

2.2 自动审计

在 Entities 文件夹里面，还有一个 Auditing 文件夹。在这个文件夹里面定义了很多对象，我们最为常用的就是 FullAuditiedEntity 对象了。从字面意思来看，它是一个包含了所有审计属性的实体。

[Serializable]
public abstract class FullAuditedEntity : AuditedEntity, IFullAuditedObject
{
    // 软删除标记，为 true 时说明实体已经被删除，反之亦然。
    public virtual bool IsDeleted { get; set; }

    // 删除实体的用户 Id。
    public virtual Guid? DeleterId { get; set; }

    // 实体被删除的时间。
    public virtual DateTime? DeletionTime { get; set; }
}

那么，什么是审计属性呢？在 ABP vNext 内部将以下属性定义为审计属性：创建人、创建时间、修改人、修改时间、删除人、删除时间、软删除标记。这些属性不需要开发人员手动去书写/控制，ABP vNext 框架将会自动跟踪这些属性并设置其值。

开发人员除了可以直接继承 FullAuditedEntity 以外，也可以考虑集成其他的审计实例，例如只包含创建人与创建时间的 CreationAuditedEntity。如果你觉得你只想要创建人、软删除标记、修改时间的话，也可以直接继承相应的接口。

public class TestEntity : Entity,IMayHaveCreator,ISoftDelete,IHasModificationTime
{
    /// 
    /// 创建人的 Id。
    /// 
    public Guid? CreatorId { get; set; }
    
    /// 
    /// 软删除标记。
    /// 
    public bool IsDeleted { get; set; }
    
    /// 
    /// 最后的修改时间。
    /// 
    public DateTime? LastModificationTime { get; set; }
}

这里我只重点提一下关于审计实体相关的内容，对于聚合的根对象的审计实体，内容也是相似的，就不再赘述。

2.3 值对象 (ValueObject)

2.3.1 基本概念

DDD 关于值对象某一个概念来说，每个值对象都是单一的副本，这个概念你可以类比 C# 里面关于值对象和引用对象的区别。

值对象与实体最大的区别就在于，值对象是没有概念标识的，还有比较重要的一点就是值对象是不可变的，所谓的不可变，就是值对象产生任何变化应该直接替换掉原有副本，而不是在原有副本上进行修改。如果值对象是可变的，那么它一定不能被共享。值对象可以引用实体或者其他的值对象。

这里仍然以书中的例子进行说明值对象的标识问题，例如 “地址” 这个概念。

如果我在淘宝买了一个键盘，我的室友也从淘宝买了同款键盘。对于淘宝系统来说，我们两个是否处于同一个地址并不重要，所以这里 “地址” 就是一个值对象。因为系统不需要关心两个地址的唯一标识是否一致，在业务上来说也没有这个需要。

另一个情况就是家里停电了，我和我的室友同时在电力服务系统提交了工单。这个时候对于电力系统来说，如果两个工单的地址是在同一个地方，那么只需要派一个人去进行维修即可。这种情况下，地址就是一个实体，因为地址涉及到比较，而比较的依据则是地址的唯一标识。

上述情况还有的另一种实现方式，即我们将住处抽象为一个实体，电力系统与住处进行关联。住处里面包含地址，这个时候地址就是一个值对象。因为这个时候电力系统关心的是住处是否一致，而地址则作为一个普通的属性而已。

关于值对象的另一个用法则更加通俗，例如一个 Person 类，他原来的定义是拥有一个 Id、姓名、街道、社区、城市。那么我们可以将街道、社区、城市抽象到一个值对象 Address 类里面，每个值对象内部包含的属性应该形成一个概念上的整体。

2.3.2 如何实现

ABP vNext 对于值对象的实现是比较粗糙的，他仅参考 MSDN 定义了一个简单的 ValueObject 类型，具体的用法开发人员可以参考 MSDN 实现值对象的细节，下文仅是摘抄部分内容进行简要描述。

MSDN 也是以地址为例，他将 Address 定义为一个值对象，如下代码。

public class Address : ValueObject
{
    public String Street { get; private set; }
    public String City { get; private set; }
    public String State { get; private set; }
    public String Country { get; private set; }
    public String ZipCode { get; private set; }

    private Address() { }

    public Address(string street, string city, string state, string country, string zipcode)
    {
        Street = street;
        City = city;
        State = state;
        Country = country;
        ZipCode = zipcode;
    }

    protected override IEnumerable