什么是DDD?

ABP框架提供了基础设施, 使基于领域驱动设计的开发更易实现.

领域驱动设计(DDD) 是一种通过将实现连接到持续进化的模型来满足复杂需求的软件开发方法.

领域驱动设计的前提是:

• 把项目的主要重点放在核心领域和领域逻辑上
• 把复杂的设计放在领域模型上
• 发起技术专家和领域专家之间的创造性协作,以迭代方式完善解决特定领域问题的概念模型

分层

ABP框架遵循DDD原则和模式去实现分层应用程序模型,该模型由四个基本层组成:

• 表示层: 为用户提供接口. 使用应用层实现与用户交互.
• 应用层: 表示层与领域层的中介,编排业务对象执行特定的应用程序任务. 使用应用程序逻辑实现用例.
• 领域层: 包含业务对象以及业务规则. 是应用程序的核心.
• 基础设施层: 提供通用的技术功能,支持更高的层,主要使用第三方类库.

领域层-实体&聚合根

实体是DDD(Domain Driven Design)中核心概念.Eric Evans是这样描述实体的 "一个没有从其属性,而是通过连续性和身份的线索来定义的对象"

实体通常映射到关系型数据库的表中.

实体类

实体都继承自Entity类,如下所示:

public class Book : Entity
{
    public string Name { get; set; }

    public float Price { get; set; }
}

如果你不想继承基类Entity,也可以直接实现IEntity接口

Entity类只是用给定的主 键类型 定义了一个Id属性,在上面的示例中是Guid类型.可以是其他类型如string, int, long或其他你需要的类型.

具有Guid主键的实体

如果你的实体Id类型为 Guid,有一些好的实践可以实现:

• 创建一个构造函数,获取ID作为参数传递给基类.如果没有为GUID Id赋值,ABP框架会在保存时设置它,但是在将实体保存到数据库之前最好在实体上有一个有效的Id.
• 如果使用带参数的构造函数创建实体,那么还要创建一个 private 或 protected 构造函数. 当数据库提供程序从数据库读取你的实体时(反序列化时)将使用它.
• 不要使用 Guid.NewGuid() 来设置Id! 在创建实体的代码中**使用IGuidGenerator服务**传递Id参数. IGuidGenerator经过优化可以产生连续的GUID.这对于关系数据库中的聚集索引非常重要.

示例实体:

public class Book : Entity
{
    public string Name { get; set; }
    public float Price { get; set; }
    protected Book()
    {
    }
    public Book(Guid id)
     : base(id)
    {
    }
}

在应用服务中使用示例:

public class BookAppService : ApplicationService, IBookAppService
{
    private readonly IRepository _bookRepository;
    public BookAppService(IRepository bookRepository)
    {
        _bookRepository = bookRepository;
    }
    public async Task CreateAsync(CreateBookDto input)
    {
        await _bookRepository.InsertAsync(
            new Book(GuidGenerator.Create())
            {
                Name = input.Name,
                Price = input.Price
            }
        );
    }
}

• BookAppService 注入图书实体的默认仓库,使用InsertAsync方法插入 Book 到数据库中.
• GuidGenerator类型是 IGuidGenerator,它是在ApplicationService基类中定义的属性. ABP将这样常用属性预注入,所以不需要手动注入.
• 如果你想遵循DDD最佳实践,请参阅下面的聚合示例部分.

具有复合键的实体

有些实体可能需要 复合键 .在这种情况下,可以从非泛型Entity类派生实体.如:

public class UserRole : Entity
{
    public Guid UserId { get; set; }

    public Guid RoleId { get; set; }
    
    public DateTime CreationTime { get; set; }

    public UserRole()
    {
            
    }
    
    public override object[] GetKeys()
    {
        return new object[] { UserId, RoleId };
    }
}

上面的例子中,复合键由UserId和RoleId组成.在关系数据库中,它是相关表的复合主键. 具有复合键的实体应当实现上面代码中所示的GetKeys()方法.

需要注意,复合主键实体不可以使用 IRepository 接口,因为它需要一个唯一的Id属性. 但你可以使用 IRepository

聚合根

聚合是领域驱动设计中的一种模式.DDD的聚合是一组可以作为一个单元处理的域对象.

例如,订单及订单系列的商品,这些是独立的对象,但将订单(连同订单系列的商品)视为一个聚合通常是很有用的

AggregateRoot类继承自Entity类,所以默认有Id这个属性, ABP 会默认为聚合根创建仓储,当然,ABP也可以为所有的实体创建仓储.

ABP不强制你使用聚合根,实际上你可以使用上面定义的Entity类,当然,如果你想实现领域驱动设计并且创建聚合根,这里有一些最佳实践仅供参考:

• 聚合根需要维护自身的完整性,所有的实体也是这样.但是聚合根也要维护子实体的完整性.所以,聚合根必须一直有效.
• 使用Id引用聚合根,而不使用导航属性
• 聚合根被视为一个单元.它是作为一个单元检索和更新的.它通常被认为是一个交易边界.
• 不单独修改聚合根中的子实体

如果你想在应用程序中实现DDD,请参阅实体设计最佳实践指南.

这是一个具有子实体集合的聚合根例子:

public class Order : AggregateRoot
{
    public virtual string ReferenceNo { get; protected set; }

    public virtual int TotalItemCount { get; protected set; }

    public virtual DateTime CreationTime { get; protected set; }

    public virtual List OrderLines { get; protected set; }

    protected Order()
    {

    }

    public Order(Guid id, string referenceNo)
    {
        Check.NotNull(referenceNo, nameof(referenceNo));
        
        Id = id;
        ReferenceNo = referenceNo;
        
        OrderLines = new List();
    }

    public void AddProduct(Guid productId, int count)
    {
        if (count <= 0 throw new argumentexception you can not add zero or negative count of products nameofcount var existingline='OrderLines.FirstOrDefault(ol'> ol.ProductId == productId);

        if (existingLine == null)
        {
            OrderLines.Add(new OrderLine(this.Id, productId, count));
        }
        else
        {
            existingLine.ChangeCount(existingLine.Count + count);
        }

        TotalItemCount += count;
    }
}

public class OrderLine : Entity
{
    public virtual Guid OrderId { get; protected set; }

    public virtual Guid ProductId { get; protected set; }

    public virtual int Count { get; protected set; }

    protected OrderLine()
    {

    }

    internal OrderLine(Guid orderId, Guid productId, int count)
    {
        OrderId = orderId;
        ProductId = productId;
        Count = count;
    }

    internal void ChangeCount(int newCount)
    {
        Count = newCount;
    }

    public override object[] GetKeys()
    {
        return new Object[] {OrderId, ProductId};
    }
}

如果你不想你的聚合根继承AggregateRoot类,你可以直接实现IAggregateRoot接口.

Order是一个具有Guid类型Id属性的 聚合根.它有一个OrderLine实体集合.OrderLine是一个具有组合键(OrderLine和 ProductId)的实体.

虽然这个示例可能无法实现聚合根的所有最佳实践,但它仍然遵循良好的实践:

• Order有一个公共的构造函数,它需要 minimal requirements 来构造一个"订单"实例.因此,在没有Id和referenceNo的时候是无法创建订单的.protected/private的构造函数只有从数据库读取对象时 反序列化 才需要.
• OrderLine的构造函数是internal的,所以它只能由领域层来创建.在Order.AddProduct这个方法的内部被使用.
• Order.AddProduct实现了业务规则将商品添加到订单中
• 所有属性都有protected的set.这是为了防止实体在实体外部任意改变.因此,在没有向订单中添加新产品的情况下设置 TotalItemCount将是危险的.它的值由AddProduct方法维护.

ABP框架不强制你应用任何DDD规则或模式.但是,当你准备应用的DDD规则或模式时候,ABP会让这变的可能而且更简单.文档同样遵循这个原则.

带有组合键的聚合根

虽然这种聚合根并不常见(也不建议使用),但实际上可以按照与上面提到的跟实体相同的方式定义复合键.在这种情况下,要使用非泛型的AggregateRoot基类.

BasicAggregateRoot类

AggregateRoot 类实现了 IHasExtraProperties 和 IHasConcurrencyStamp 接口,这为派生类带来了两个属性. IHasExtraProperties 使实体可扩展和 IHasConcurrencyStamp 添加了由ABP框架管理的 ConcurrencyStamp 属性实现乐观并发. 在大多数情况下,这些是聚合根需要的功能.

但是,如果你不需要这些功能,你的聚合根可以继承 BasicAggregateRoot(或BasicAggregateRoot).

基类和接口的审计属性

有一些属性,像CreationTime,CreatorId,LastModificationTime...在所有应用中都很常见. ABP框架提供了一些接口和基类来标准化这些属性,并自动设置它们的值.

审计接口

有很多的审计接口,你可以实现一个你需要的那个.

• IHasCreationTime 定义了以下属性:CreationTime
• IMayHaveCreator 定义了以下属性:CreatorId
• ICreationAuditedObject 继承 IHasCreationTime 和 IMayHaveCreator, 所以它定义了以下属性:CreationTimeCreatorId
• IHasModificationTime 定义了以下属性:LastModificationTime
• IModificationAuditedObject 扩展 IHasModificationTime 并添加了 LastModifierId 属性. 所以它定义了以下属性:LastModificationTimeLastModifierId
• IAuditedObject 扩展 ICreationAuditedObject 和 IModificationAuditedObject, 所以它定义了以下属性:CreationTimeCreatorIdLastModificationTimeLastModifierId
• ISoftDelete 定义了以下属性:IsDeleted
• IHasDeletionTime 扩展 ISoftDelete 并添加了 DeletionTime 属性. 所以它定义了以下属性:IsDeletedDeletionTime
• IDeletionAuditedObject 扩展 IHasDeletionTime 并添加了 DeleterId 属性. 所以它定义了以下属性:IsDeletedDeletionTimeDeleterId
• IFullAuditedObject 继承 IAuditedObject 和 IDeletionAuditedObject, 所以它定义了以下属性:CreationTimeCreatorIdLastModificationTimeLastModifierIdIsDeletedDeletionTimeDeleterId

当你实现了任意接口,或者从下一节定义的类派生,ABP框架就会尽可能地自动管理这些属性.

实现 ISoftDelete , IDeletionAuditedObject 或 IFullAuditedObject 让你的实体软删除.

审计基类

虽然可以手动实现以上定义的任何接口,但建议从这里定义的基类继承:

• CreationAuditedEntity 和 CreationAuditedAggregateRoot 实现了 ICreationAuditedObject 接口.
• AuditedEntity 和 AuditedAggregateRoot 实现了 IAuditedObject 接口.
• FullAuditedEntity and FullAuditedAggregateRoot 实现了 IFullAuditedObject 接口.

所有这些基类都有非泛型版本,可以使用 AuditedEntity 和 FullAuditedAggregateRoot 来支持复合主键;

所有这些基类也有 ... WithUser,像 FullAuditedAggregateRootWithUser 和 FullAuditedAggregateRootWithUser. 这样就可以将导航属性添加到你的用户实体. 但在聚合根之间添加导航属性不是一个好做法,所以这种用法是不建议的(除非你使用EF Core之类的ORM可以很好地支持这种情况,并且你真的需要它. 请记住这种方法不适用于NoSQL数据库(如MongoDB),你必须真正实现聚合模式）.