本章內容還在整理上傳中，你可以等全部更新完畢後再查閱也可以先預覽已上傳的內容。。。。。。 7. 應用層的命令模式 在上個章節里我們設計並編碼了領域對象Permission，但是目前Permission並沒有任何行為上的設計。這是因為我們不建議“憑空去製造行為”，而是在領域對象第一個版本的代碼實現之後 ...
本章內容還在整理上傳中，你可以等全部更新完畢後再查閱也可以先預覽已上傳的內容。。。。。。
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;
}
}
}
1）public sealed class CreatePermission : Command<Permission>，類型CreatePermission繼承自命令的泛型版本Command<T>，泛型參數表示該命令需要返回類型為T的結果，這裡表示的是執行CreatePermission命令後，需要返回一個Permission許可權對象。Command<T>來自CodeArt.DomainDriven命名空間，由程式集CodeArt.DomainDriven提供。CA規定除了查詢操作外所有命令對象都需要繼承自Command或Command<T>。
2） private string _name; 私有成員 _name用於接收外界傳遞的許可權名稱的參數，請註意，因為name是必填項，所以以構造函數參數的形式強制要求外界必須傳遞name。名稱為什麼必填？ 這跟傳統開發里表單必填項沒有任何關係，而是因為領域模型Permission的屬性Name定義的固定規則包含了不能為空的限制。
3）Description和MarekdCode被設計成為屬性並且公開了GET和SET方法，表示外界可以為許可權選擇性填寫描述和標識碼。請註意這不是領域屬性，這是命令為了接收參數而編寫的.NET屬性，事實上你可以為這兩個屬性任意命名（比如 desp或mc，不過考慮可閱讀性我們沒有這樣命名）。這兩個屬性之所以不必填也是由於Permission對應的屬性規則導致的，不再覆述。
4）
