從零開始使用CodeArt實踐最佳領域驅動開發（五）
本章內容還在整理上傳中，你可以等全部更新完畢後再查閱也可以先預覽已上傳的內容。。。。。。
7. 應用層的命令模式
在上個章節裏我們設計並編碼了領域對象Permission，但是目前Permission並沒有任何行為上的設計。這是因為我們不建議“憑空去制造行為”，而是在領域對象第一個版本的代碼實現之後就立即使用它。在使用過程中觀察外界（應用層或其他領域對象）對它的需求，這些需求往往暗藏了進一步揭露對象本質特征的提示。我們可以根據這些提示逐漸挖掘出該對象更多的行為特征，結合CA裏相關的設計原則，最終我們可以確認領域對象該如何提供哪些行為方法。所以，大家不要在意領域對象在設計初期有點類似“貧血模型”，因為這不是它的最終形態，這只是它成長的起點。那如果經過一番嘗試後，我們還是沒有為對象添加任何方法呢？這種情況的確存在，有些對象存在的意義只是被別的對象引用，自身並沒有提供任何行為方法，但是如果你的項目裏大量充斥著沒有行為的領域對象，這就值得你警惕了，肯定是設計上出現了重大的錯
因此，我們暫且放下對領域模型的思考，將思路轉移到應用層，考慮應用層對Permission有什麽需求。涉及到應用層我們又不得不考慮表現層對應用層會有哪些需求，最終我們會發現要思考的問題其實是終端用戶會有什麽需求。所以，我們考慮第一個問題：用戶怎麽使用權限機制？這個話題在前文也討論過，這裏我們只用考慮用戶使用權限的第一個必須操作是什麽？
當然是為項目創建權限描述了，我們需要定義整個項目提供了哪些權限，只有定義了權限信息後系統才能以此為參考識別登錄者可以使用哪些功能。因此，創建權限信息是用戶的第一個操作需要。但是我們要從使用者的角度對這個需求點進一步修正：“系統管理員可以定義整個項目提供了哪些功能”。系統管理員指的是項目搭建好後，設置項目初始參數的人，這類人比普通用戶更加了解系統（往往是我們自己）。從UI界面操作體驗上來講，提示使用者“定義整個項目提供了哪些功能”比“定義整個項目提供了哪些權限”要更容易理解。
分析到這裏，我們就知道不論UI界面怎麽描述，應用層都要提供“創建權限”的功能。所以我們以創建權限為示例講述如何建立應用層的命令。
在CA的4層架構裏，應用層由服務和子系統提供的命令組成。也就是說，AccountSubsystem裏除了定義領域模型的內容外還會提供一組命令給外界使用，這組命令我們將其劃分為應用層的範圍。請大家註意，CA裏的層次結構是一個概念而不是真實的物理布局。雖然不同的層次往往物理布局不一樣，但是也有例外的時候，這裏的子系統提供的命令就是和領域模型在一個程序集裏，但是所處不同的層次結構，命令屬於應用層，領域對象屬於領域模型層。（當然，你就算不理解這點也無所謂，對開發項目沒什麽影響。）
下面貼出創建權限的命令代碼並作出說明：
using System;
using System.Linq;
using CodeArt;
using CodeArt.DomainDriven;
namespace AccountSubsystem
{
public sealed class CreatePermission : Command<Permission>
{
private string _name;
public string Description
{
get;
set;
}
public string MarkedCode
{
get;
set;
}
public CreatePermission(string name)
{
_name = name;
}
protected override Permission ExecuteProcedure()
{
Permission permission = new Permission(Guid.NewGuid())
{
Name = _name,
MarkedCode = this.MarkedCode ?? string.Empty,
Description = this.Description ?? string.Empty
};
var repository = Repository.Create<IPermissionRepository>();
repository.Add(permission);
return permission;
}
}
}
這是一段非常簡單的命令代碼，
從零開始使用CodeArt實踐最佳領域驅動開發（五）