实现领域驱动设计 - 使用ABP框架 - 创建实体

用例演示 - 创建实体

本节将演示一些示例用例并讨论可选场景。

创建实体

从实体/聚合根类创建对象是实体生命周期的第一步。聚合/聚合根规则和最佳实践部分 建议为Entity类创建一个主构造函数，以保证创建一个有效的实体。因此，无论何时我们需要创建实体的实例，我们都应该使用那个构造函数

参见下面的问题聚合根类:

public class Issue : AggregateRoot<Guid>
{
    public Guid RepositoryId { get; private set; }
    public string Title { get; private set; }
    public string Text { get; set; }
    public Guid? AssignedUserId { get; private set; }
    
    public Issue(
        Guid id, 
        Guid repositoryId,
        string title,
        string text = null
    ) : base(id)
    {
        RepositoryId = repositoryId;
        Title = Check.NotNullOrWhiteSpace(title, nameof(title));
        Text = text; // 允许空值
    }

    private Issue() { //为ORM保留的空构造函数 }

    public void SetTitle(string title)
    {
        Title = Check.NotNullOrWhiteSpace(title, nameof(title));
    }
}

• 该类保证通过其构造函数创建有效的实体。

• 如果你需要更改标题，你需要使用 SetTitle 方法保证标题在一个有效状态

• 如果您想将这个问题分配给用户，您需要使用 IssueManager (它在分配之前实现了一些业务规则, 请参阅我之前关于 领域服务 的文章)。

• Text 属性有一个公共setter，因为它也接受null值，并且这个示例没有任何验证规则。它在构造函数中也是可选的

让我们看看用于创建问题的Application Service方法:

public class IssueAppService : ApplicationService, IIssueAppService
{
    //省略了Repository和DomainService的依赖注入

    [Authorize]
    public async Task<IssueDto> CreateAsync(IssueCreationDto input)
    {
        //创建一个有效的问题实体
        var issue = new Issue(
            GuidGenerator.Create(),
            input.RepositoryId,
            input.Title,
            input.Text
        );

        //如果传入了被分配人,则把该问题法分配给这个用户
        if(input.AssignedUserId.HasValue)
        {
            var user = await _userRepository.GetAsync(input.AssignedUserId.Value);
            await _issueManager.AssignToAsync(issue, user);
        }

        // 把问题实体保存到数据库
        await _issueRepository.InsertAsync(issue);

        //返回表示这个新的问题的DTO
        return ObjectMapper.Map<Issue, IssueDto>(issue);
    }
}

CreateAsync 方法:

• 使用 Issue 构造函数创建有效的问题。它使用 IGuidGenerator 服务传递Id。这里不使用自动对象映射
• 如果客户端希望在对象创建时将这个问题分配给用户，它会使用IssueManager 来完成，允许 IssueManager 在分配之前执行必要的检查。
• 保存实体到数据库
• 最后使用 IObjectMapper 返回一个 IssueDto ，该 IssueDto 是通过映射从新的 Issue 实体自动创建的

使用领域规则创建实体

上述示例, Issue 没有关于实体创建的业务规则，除了在构造函数中进行一些形式的验证。但是，在某些情况下，实体创建应该检查一些额外的业务规则

例如，假设您不希望在完全相同的标题已经存在问题的情况下创建问题。在哪里实现这个规则? 在 Application Service 中实现此规则是不合适的，因为它是一个应该始终检查的 核心业务(领域)规则

该规则应该在 领域服务 (在本例中是 IssueManager )中实现。因此，我们需要强制应用层总是使用 IssueManager 来创建一个新的 Issue

首先，我们可以将 Issue 构造函数设置为 internal ，而不是 public:

public class Issue : AggregateRoot<Guid>
{
    internal Issue(
        Guid id, 
        Guid repositoryId,
        string title,
        string text = null
    ) : base(id)
    {
        //...
    }
}

这阻止了应用服务直接使用构造函数，所以它们将使用 IssueManager 。然后我们可以在 IssueManager 中添加一个 CreateAsync 方法:

public class IssueManager : DomainService
{
    //省略了依赖注入

    public async Task<IssueDto> CreateAsync(
        Guid repositoryId,
        string title,
        string text = null
    )
    {
        //如果存在相同标题的问题,直接抛错
        if(await _issueRepository.AnyAsync(i => i.Title == title))
        {
            throw new BusinessException("IssueTracking:IssueWithSameTitleExists");
        }

        //创建一个有效的问题实体
        return new Issue(
            GuidGenerator.Create(),
            repositoryId,
            title,
            text
        );
    }
}

• CreateAsync 方法检查相同标题是否已经存在问题，并在这种情况下抛出业务异常
• 如果没有重复，则创建并返回一个新的Issue

为了使用上述方法，IssueAppService 被修改如下:

public class IssueAppService : ApplicationService, IIssueAppService
{
    //省略了依赖注入

    public async Task<IssueDto> CreateAsync(IssueCreationDto input)
    {
        //★修改为通过领域服务创建有效的问题实体, 而不是直接new
        var issue = await _issueManager.CreateAsync(
            GuidGenerator.Create(),
            input.RepositoryId,
            input.Title,
            input.Text
        );

        //如果传入了被分配人,则把该问题法分配给这个用户
        if(input.AssignedUserId.HasValue)
        {
            var user = await _userRepository.GetAsync(input.AssignedUserId.Value);
            await _issueManager.AssignToAsync(issue, user);
        }

        // 把问题实体保存到数据库
        await _issueRepository.InsertAsync(issue);

        //返回表示这个新的问题的DTO
        return ObjectMapper.Map<Issue, IssueDto>(issue);
    }
}

讨论:为什么问题没有在 IssueManager 中保存到数据库?

你可能会问 “为什么 IssueManager 不把问题保存到数据库中?” 我们认为这是应用服务的责任

因为，在保存问题对象之前，应用程序服务可能需要对其进行额外的更改/操作。如果领域服务保存它，则保存操作将重复

• 两次数据库往返会导致性能损失
• 需要显式的数据库事务来包含这两个操作
• 如果由于业务规则的原因，其他操作取消了实体创建，则应该在数据库中回滚事务

当你检查 IssueAppService 时，你会看到在 IssueManager.CreateAsync 中不保存 Issue 到数据库的好处。否则，我们将需要执行一次插入(在 IssueManager 中)和一次更新(在分配问题之后)

讨论:为什么不在应用程序服务中实现重复标题检查?

我们可以简单地说 “因为它是一个核心领域逻辑，应该在领域层中实现”。然而，这带来了一个新的问题: “您如何判断它是核心领域逻辑，而不是应用程序逻辑?” (稍后我们将详细讨论其中的差异)

对于这个例子，一个简单的问题可以帮助我们做出决定: “如果我们有另一种方法(用例)来创建一个问题，我们是否仍然应用相同的规则?” 你可能会想 “为什么我们有第二种制造问题的方式?” 然而，在现实生活中，你有:

• 应用程序的最终用户可能会在应用程序的标准UI中创建问题(比如在github的网页端创建问题)
• 您可能有第二个后台应用程序，由您自己的员工使用，您可能希望提供一种创建问题的方法(在本例中可能使用不同的授权规则)
• 您可能有一个对第三方客户端开放的HTTP API，他们会创建问题。
• 您可能有一个 background worker service，如果它检测到一些故障，它会做一些事情并创建问题。这样，它将在没有任何用户交互的情况下(可能没有任何标准的授权检查)创建问题。
• 您甚至可以在UI上设置一个按钮，将某些内容 (例如，讨论) 转换为问题

综上所述，不同的应用程序始终遵循这样的规则:新问题的标题不能与任何现有问题的标题相同!他们与应用层无关! 这就是为什么该逻辑是核心领域逻辑，应该位于领域层中，而不应该在应用程序服务中实现为重复的代码。