实现领域驱动设计 - 使用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的依赖注入
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上设置一个按钮，将某些内容 (例如，讨论) 转换为问题
综上所述，不同的应用程序始终遵循这样的规则:新问题的标题不能与任何现有问题的标题相同!他们与应用层无关! 这就是为什么该逻辑是核心领域逻辑，应该位于领域层中，而不应该在应用程序服务中实现为重复的代码。
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！
页:
[1]