如何实现领域驱动设计

存储库 Repository 是一个类似于集合的接口，领域层和应用程序层使用它来访问数据持久性系统(数据库)，以读写业务对象(通常是聚合) 常见的存储库原则是

存储库

Repository 是一个类似于集合的接口，领域层和应用程序层使用它来访问数据持久性系统(数据库)，以读写业务对象(通常是聚合)

常见的存储库原则是:

在领域层定义一个存储库接口(因为它被用于领域层和应用层)，在基础设施层实现(启动模板中的EntityFrameworkCore项目)

不要在存储库中包含业务逻辑。

存储库接口应该是独立于数据库提供者/ ORM的。例如，不要从存储库方法返回DbSet。DbSet是 EF Core 提供的一个对象

为聚合根创建存储库，而不是为所有实体。因为，子集合实体(聚合的)应该通过聚合根访问

不要在存储库中包含领域逻辑

虽然这个规则在一开始看起来很明显，但是很容易将业务逻辑泄露到存储库中

示例:从存储库中获取不活跃的问题

public interface IIssueRepository : IRepository<Issue, Guid>
{
    Task<List<Issue>> GetInActiveIssuesAsync();
}

IIssueRepository 扩展了标准 IRepository<...> 接口，添加GetInActiveIssuesAsync 方法。这个存储库使用这样一个Issue类:

public class Issue : AggregateRoot<Guid>, IHasCreationTime
{
    public bool IsClosed { get; private set; }
    public Guid? AssignedUserId { get; private set; }
    public DateTime CreationTime { get; private set; }
    public DateTime? LastCommentTime { get; private set; }
}

(代码只显示了本例所需的属性)

规则规定存储库不应该知道业务规则。这里的问题是 “什么是不活跃的问题? ”它是业务规则定义吗?”

让我们看看实现来理解它:

public class EfCoreIssueRepository : 
    EfCoreRepository<IssueTrackingDbContext, Issue, Guid>
    IIssueRepository
{
    public async Task<List<Issue>> GetInActiveIssuesAsync()
    {
        var daysAgo30 = DateTime.Now.Subtract(TimeSpan.FromDays(30));
        var dbSet = await GetDbSetAsync();
        return await dbSet.Where(i => 
            //开放的
            !i.IsClosed &&

            //没有分配给任何人
            i.AssignedUserId == null &&

            //30天前创建的
            i.CreationTime < daysAgo30 &&

            //最近30天内没有任何评论
            (i.LastCommentTime == null || i.LastCommentTime < daysAgo30)
            
            ).ToListAsync();
    }
}

(使用EF Core实现。查看 EF Core集成文档，了解如何使用 EF Core 创建自定义存储库。)

当我们检查 GetInActiveIssuesAsync 的实现时，我们看到了一个业务规则，它给出了不活跃的问题的定义:该问题应该是开放的，没有分配给任何人，30天前创建的，并且在最近30天内没有任何评论

这是隐藏在存储库方法中的业务规则的隐式定义。当我们需要重用该业务逻辑时，就会出现问题

例如，假设我们想要在 Issue 实体上添加一个 bool IsInActive() 方法。这样，当我们有 Issue 实体时，我们就可以检查活跃度。

让我们看看实现:

public class Issue : AggregateRoot<Guid>, IHasCreationTime
{
    public bool IsClosed { get; private set; }
    public Guid? AssignedUserId { get; private set; }
    public DateTime CreationTime { get; private set; }
    public DateTime? LastCommentTime { get; private set; }

    public bool IsInActive()
    {
        var daysAgo30 = DateTime.Now.Subtract(TimeSpan.FromDays(30));
        return 
            //开放的
            !IsClosed &&

            //没有分配给任何人
            AssignedUserId == null &&

            //30天前创建的
            CreationTime < daysAgo30 &&

            //最近30天内没有任何评论
            (LastCommentTime == null || LastCommentTime < daysAgo30);
    }
}

我们必须复制/粘贴/修改代码。如果活动性的定义改变了呢?我们不应该忘记更新这两个地方。这是业务逻辑的重复，这是非常危险的

这个问题的一个很好的解决方案是规范模式!

规范

规范是一个命名的、可重用的、可组合的和可测试的类，用于基于业务规则筛选领域对象

ABP框架提供了必要的基础设施来轻松地创建规范类并在应用程序代码中使用它们。让我们将不活跃的问题过滤器实现为一个规范类:

public class InActiveIssueSpecification : Specification<Issue>
{
    public override Expression<Func<Issue,bool>> ToExpression()
    {
        var daysAgo30 = DateTime.Now.Subtract(TimeSpan.FromDays(30));
        return i =>
            //开放的
            !i.IsClosed &&

            //没有分配给任何人
            i.AssignedUserId == null &&

            //30天前创建的
            i.CreationTime < daysAgo30 &&

            //最近30天内没有任何评论
            (i.LastCommentTime == null || i.LastCommentTime < daysAgo30);
    }
}

Specification<T> 基类通过定义表达式简化了创建规范类的工作。只是将表达式从存储库移到这里
现在我们就可以在 Issue 实体和 EfCoreIssueRepository 类中复用 InActiveIssueSpecification 了

在实体中使用规范

Specification 类提供了一个 IsSatisfiedBy 方法，如果给定的对象(实体)满足规范，该方法返回true。我们可以重写这个 Issue。IsInActive 方法如下所示:

public class Issue : AggregateRoot<Guid>, IHasCreationTime
{
    public bool IsInActive()
    {
       return new InActiveIssueSpecification().IsSatisfiedBy(this);
    }
}

在存储库中使用规范

首先，从存储库接口开始:

public interface IIssueRepository : IRepository<Issue, Guid>
{
    Task<List<Issue>> GetIssuesAsync(ISpecification<Issue> spec);
}

将 GetInActiveIssuesAsync 重命名为简单的 GetIssuesAsync, 并接受一个规范对象

由于规范(过滤器)已经从存储库中移出，我们不再需要创建不同的方法来获得不同条件下的问题(比如: GetAssignedIssues(...) , GetLockedIssues(...) 等等)

更新后的存储库实现可以像这样:

public class EfCoreIssueRepository : 
    EfCoreRepository<IssueTrackingDbContext, Issue, Guid>
    IIssueRepository
{
    public async Task<List<Issue>> GetIssuesAsync(ISpecification<Issue> spec)
    {
        var dbSet = await GetDbSetAsync();
        return await dbSet
            .Where(spec.ToExpression())
            .ToListAsync();
    }
}

因为ToExpression()方法返回一个表达式，所以它可以直接传递给Where方法来过滤实体

最终,我们做到了业务逻辑的代码复用,消除了安全隐患

使用默认的存储库

实际上，您不必创建自定义存储库才能使用规范。标准的IRepository已经扩展了IQueryable，所以你可以在上面使用标准的LINQ扩展方法:

public class IssueAppService : ApplicationService, IIssueAppService
{
    public async Task<List<Issue>> GetInActiveIssuesAsync()
    {
        var queryable = await _issueRepository.GetQueryableAsync();
        var issues = await AsyncExecuter.ToListAsync(
            queryable.Where(new InActiveIssueSpecification())
        );
    }
}

AsyncExecuter 是ABP框架提供的一个实用工具，用于使用异步LINQ扩展方法(如这里的ToListAsync)，而不依赖于EF Core NuGet包。有关更多信息，请参阅 Repositories文档

组合规范

规范的一个强大的方面是它们是可组合的。假设我们有另一个规范，它只在问题位于里程碑时返回true

public class MilestoneSpecification : Specification<Issue>
{
    public Guid MilestoneId { get; }
    public override Expression<Func<Issue,bool>> ToExpression()
    {
        return i => i.MilestoneId == MilestoneId;
    }
}

本规范是参数化的，与 InActiveIssueSpecification 有所不同。我们可以结合这两个规范来获得特定里程碑中的非活跃问题列表

public class IssueAppService : ApplicationService, IIssueAppService
{
    public async Task<List<Issue>> GetInActiveIssuesWithinMilestoneAsync(Guid milestoneId)
    {
        var queryable = await _issueRepository.GetQueryableAsync();
        var issues = await AsyncExecuter.ToListAsync(
            queryable.Where(
                new InActiveIssueSpecification()
                .And(new MilestoneSpecification(milestoneId))
                .ToExpression()
            )
        );
    }
}

上面的示例使用And扩展方法来组合这些规范。还有更多的组合方法可用，比如 Or(…) 和 AndNot(…)

有关ABP框架提供的规范基础架构的更多细节，请参阅规范文档。

转 https://www.cnblogs.com/broadm/p/16405389.html

全站频道

大家都在搜索：

存储库