4.第一個示例的編碼工作

　　使用CA編碼項目的核心結構是：由多個子系統組成多個不同的服務來提供項目的各種功能。請不要將這裏提到的子系統與大家在別的項目實施方法裏的概念混為一談，CA裏的子系統概念是完全不一樣的，下面我們詳細闡述這一點。

　　同一事物在不同領域裏的本質特征是不盡相同的，例如書在銷售領域的關註點是價格、好評度、熱銷情況等。但在閱讀領域裏，書更多的關註點是頁碼、每頁內容、段落註釋等特征。因此，要想用常規的方法在不同領域重用同一個事物模型是非常困難的。CA為了解決這類問題將整個項目切分為多個子系統，每個子系統關註各自領域內的特征。這些子系統是真正實現業務邏輯的地方，子系統之間會存在一定的依賴關系，但是這種依賴關系是良性的，不會影響系統的重用性。也就是說，每個子系統都可以單獨拿出來引用到別的項目子系統中擴展重用。開發人員可以根據需要將多個子系統組裝在一起構成一個新的服務，這項服務適用於某一個特定領域，例如：

　　文章子系統 + 汽車子系統 = 提供汽車文集的服務（汽車門戶站點）

　　相冊子系統 + 用戶子系統 = 提供用戶管理個人相冊的服務（社交項目）

　　銷售子系統 + 書籍子系統 = 書籍貿易（電商站點）

　　從層次結構上來講，服務屬於應用層，直接對表現層負責。子系統裏的領域對象及業務代碼則屬於領域模型層。應用層調用領域模型提供的領域方法以便完成業務需求。

　　一個項目無論規模多麽龐大都可以劃分成多個規模量為1的子系統，由於這些子系統的代碼量足夠少，所以可維護性極高。與傳統開發的模式相比，CA裏的子系統特點如下：

　　1） 子系統不是抽象的概念而是真實存在的代碼集合。在.Net平臺裏一個子系統體現為一個程序集。

　　2） 子系統內部僅關註於領域模型的建立，沒有任何數據存儲的代碼。數據的存儲由基礎設施層裏的數據倉儲提供。這意味著你可以隨時改變存儲的機制：切換數據庫類型、改變表結構、分布式部署數據庫等持久化操作都不會影響到領域模型的改變。

　　3） 子系統不僅僅用於一個項目，它可以被任意項目使用。以.Net平臺為例，子系統有自己所在的解決方案。當其他項目要使用該子系統時，可以以項目引用、程序集引用等方式重用子系統，但絕對不是復制粘貼源代碼到新項目裏。子系統的源代碼只有一份，升級子系統會讓所有使用它的項目收益。

　　4） 多個子系統可以集成工作，一個子系統裏的領域模型是可以被其他子系統擴展的。這裏說的擴展是指在不破壞原有代碼的情況下，以繼承、組合等方式擴充領域模型的能力。與這種方式相比，很多傳統開發模式裏所謂的“二次開發”就是把以前做過的代碼、設計過的數據庫表復制到新項目裏，再更改源代碼和表設計以滿足新的需求，這根本就不是擴展而是重寫。

　　5） 子系統不能直接用於表現層，它們工作的場所是在應用層的服務裏。你可以使用任意技術搭建服務。在.Net平臺下可以部署在IIS裏，也可以使用專用於CA的服務器端應用程序部署項目的服務。

　　有了CA開發項目的結構說明和之前分析原始需求的結果，我們可以繼續展開會議系統的編碼工作了。

　　根據前文所述，我們要先為“菜單”、“功能”、“用戶”、“角色”等事物創建一個服務，服務會提供各種接口以供表現層調用，例如：創建菜單、新增功能描述等服務接口。請註意，把“菜單”、“功能”、“用戶”、“角色”這些事物放在同一個服務裏未必正確，我們會在後續的開發工作裏基於各種原則將服務分離，創建多個服務、多個子系統。但是在眼前我們不必過多考慮這一點，大膽的去做吧。

　　為服務命名是我們要考慮的第一件事。大家不要忽略命名的重要性，為服務命名、為子系統命名、為領域對象、領域屬性、領域方法命名都是需要你認真對待的工作。經過一番思考後，我們認為“菜單”、“功能”、“用戶”、“角色”等事物是一個項目裏幾乎必備的事物，是一切的源頭。所以我們引用門戶（Portal）這個詞作為服務的名稱，表示系統的入口，因此服務的全稱為PortalService。

　　以.Net平臺為例，我們為門戶服務建立解決方案PortalService的結構如下圖：

　　1） 解決方案文件夾Framework裏引用的是CA提供的部分類庫，在後續教程裏會詳細說明這些庫的用法。在這裏我們只用知道引用的這幾個庫是構建服務必不可缺的。

　　2） 解決方案文件夾Subsystems表示服務需要用到的子系統，目前服務沒有引用任何子系統，稍後我們會創建。

　　3） portal.services.codeart.cn是托管至IIS的門戶服務站點，你也可以使用其他技術部署服務，在這裏我們以站點為例。

　　4） PortalService.Application是門戶服務的應用程序集，在這個程序集裏主要使用子系統提供的應用命令來完成服務的調用，後面會有詳細的說明。

　　5） PortalServiceTest是單元測試程序集。

　　創建完門戶服務解決方案後，我們需要為其添加子系統。正確的劃分子系統是使用CA的一項重要工作。你可以從以下幾個角度去分析如何找出子系統：

　　1） 在已知的事物裏，哪些事物是最獨立的？獨立是指構建該事物的模型不會依賴於其他事物的模型。由於菜單、角色都會涉及到功能的分配，它們的領域模型與功能肯定會有某種依賴關系，所以我們認為菜單和角色這兩個事物不不夠獨立。那麽“功能”呢？描述系統的功能只需要一個簡單的名稱和描述即可，不會依賴任何其他事物而存在，所以”功能“足夠獨立。我們以“功能”為突破口找出潛在的子系統。

　　2） 為獨立的事物正名。只要是確定要為其建立模型的事物，我們都需要考慮它的名稱是否合理。因為我們得到的事物是從現實世界裏表面需求分析而來的，這樣的事物並非真正貼切程序裏的領域模型，在程序世界裏有其獨有的描述方式。“功能” 這個名稱比較含糊，能代表的概念很多，不適用於程序命名。另外，我們在談及到角色的時候，不是角色有哪些功能而是角色擁有哪些權限。所以，將“功能”正名為“權限”是一個不錯的主意。我們統一語言後，會將之前分析到的需求更改為“可以為角色分配權限”、“可以為菜單設置哪些權限能夠使用它”。

　　3） 確定了獨立事物的名稱後，我們就能以此為基礎假設要建立一個與該事物相關的子系統。在這個例子裏也就是“權限子系統”。目前，該子系統需要提供哪些應用上的幫助我們還比較模糊，但是可以確定的是權限子系統需要提供創建權限、修改權限、刪除權限等操作。權限子系統裏面一定會有權限的領域模型。

　　4） 事實上分析到第3步就可以編碼完成權限子系統的第一個版本了，但是由於我們提供的是使用CA的教程，不可能完全演繹出真實項目叠代實施的每個細節，真要如此需要寫一本獨立的書籍了，也許以後我會抽時間去著作完成，但是在這裏我們會濃縮下項目實施的過程。提前告知各位正確的設計方式。“權限子系統”這個想法很好，從概念上講幾乎無懈可擊，但是從務實的角度來考慮會有些問題。如果我們為一個領域模型去創建一個子系統，這樣使用起來會比較麻煩。你試想一下，如果有“菜單子系統”、“角色子系統”、“權限子系統”，當我們要在服務裏創建一個角色時，這個服務必須引用“角色子系統”和“權限子系統”才能完成工作，如果對象引用鏈比較多，你有可能需要引用的子系統數量遠超過預，例如：用戶子系統會引用賬戶子系統、賬戶子系統會引用權限子系統和角色子系統、用戶子系統還會引用地理位置子系統用以表示用戶所在地。這時候服務要使用用戶子系統就不得不多引用4個額外的項目，不僅麻煩也不利於維護更新。關於如果切斷引用鏈，讓子系統更加的獨立的話題後面會有更詳細的說明，這裏我們只用知道盡量不要為一個事物單獨創建子系統。

CodeArt入門教程（二）