用例演示 - 創建實體 本節將演示一些示例用例並討論可選場景。 創建實體 從實體/聚合根類創建對象是實體生命周期的第一步。聚合/聚合根規則和最佳實踐部分 建議為Entity類創建一個主構造函數，以保證創建一個有效的實體。因此，無論何時我們需要創建實體的實例，我們都應該使用那個構造函數 參見下麵的問題 ...
用例演示 - 創建實體
本節將演示一些示例用例並討論可選場景。
創建實體
從實體/聚合根類創建對象是實體生命周期的第一步。聚合/聚合根規則和最佳實踐部分 建議為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上設置一個按鈕，將某些內容 (例如，討論) 轉換為問題
綜上所述，不同的應用程式始終遵循這樣的規則:新問題的標題不能與任何現有問題的標題相同!他們與應用層無關! 這就是為什麼該邏輯是核心領域邏輯，應該位於領域層中，而不應該在應用程式服務中實現為重覆的代碼。
