4.劃分子系統 使用CA編碼項目的核心結構是：由多個子系統組成多個不同的服務來提供項目的各種功能。請不要將這裡提到的子系統與大家在別的項目實施方法里的概念混為一談，CA里的子系統概念是完全不一樣的，下麵我們詳細闡述這一點。 同一事物在不同領域里的本質特征是不盡相同的，例如書在銷售領域的關註點是價格、 ...
4.劃分子系統
使用CA編碼項目的核心結構是：由多個子系統組成多個不同的服務來提供項目的各種功能。請不要將這裡提到的子系統與大家在別的項目實施方法里的概念混為一談，CA里的子系統概念是完全不一樣的，下麵我們詳細闡述這一點。
同一事物在不同領域里的本質特征是不盡相同的，例如書在銷售領域的關註點是價格、好評度、熱銷情況等。但在閱讀領域里，書更多的關註點是頁碼、每頁內容、段落註釋等特征。因此，要想用常規的方法在不同領域重用同一個事物模型是非常困難的。CA為瞭解決這類問題將整個項目切分為多個子系統，每個子系統關註各自領域內的特征。這些子系統是真正實現業務邏輯的地方，子系統之間會存在一定的依賴關係，但是這種依賴關係是良性的，不會影響系統的重用性。也就是說，每個子系統都可以單獨拿出來引用到別的項目子系統中擴展重用。開發人員可以根據需要將多個子系統組裝在一起構成一個新的服務，這項服務適用於某一個特定領域，例如：
文章子系統 + 汽車子系統 = 提供汽車文集的服務（汽車門戶站點）
相冊子系統 + 用戶子系統 = 提供用戶管理個人相冊的服務（社交項目）
銷售子系統 + 書籍子系統 = 書籍貿易（電商站點）
從層次結構上來講，服務屬於應用層，直接對錶現層負責。子系統里的領域對象及業務代碼則屬於領域模型層。應用層調用領域模型提供的領域方法以便完成業務需求。
一個項目無論規模多麼龐大都可以劃分成多個規模量為1的子系統，由於這些子系統的代碼量足夠少，所以可維護性極高。與傳統開發的模式相比，CA里的子系統特點如下：
1） 子系統不是抽象的概念而是真實存在的代碼集合。在.Net平臺里一個子系統體現為一個程式集。
2） 子系統內部僅關註於領域模型的建立，沒有任何數據存儲的代碼。數據的存儲由基礎設施層里的數據倉儲提供。這意味著你可以隨時改變存儲的機制：切換資料庫類型、改變表結構、分散式部署資料庫等持久化操作都不會影響到領域模型的改變。
3） 子系統不僅僅用於一個項目，它可以被任意項目使用。以.Net平臺為例，子系統有自己所在的解決方案。當其他項目要使用該子系統時，可以以項目引用、程式集引用等方式重用子系統，但絕對不是複製粘貼源代碼到新項目里。子系統的源代碼只有一份，升級子系統會讓所有使用它的項目收益。
4） 多個子系統可以集成工作，一個子系統里的領域模型是可以被其他子系統擴展的。這裡說的擴展是指在不破壞原有代碼的情況下，以繼承、組合等方式擴充領域模型的能力。與這種方式相比，很多傳統開發模式里所謂的“二次開發”就是把以前做過的代碼、設計過的資料庫表複製到新項目里，再更改源代碼和表設計以滿足新的需求，這根本就不是擴展而是重寫。
5） 子系統不能直接用於表現層，它們工作的場所是在應用層的服務里。你可以使用任意技術搭建服務。在.Net平臺下可以部署在IIS里，也可以使用專用於CA的伺服器端應用程式部署項目的服務。
有了CA開發項目的結構說明和之前分析原始需求的結果，我們可以繼續展開會議系統的編碼工作了。
根據前文所述，我們要先為“菜單”、“功能”、“用戶”、“角色”等事物創建一個服務，服務會提供各種介面以供表現層調用，例如：創建菜單、新增功能描述等服務介面。請註意，把“菜單”、“功能”、“用戶”、“角色”這些事物放在同一個服務里未必正確，我們會在後續的開發工作里基於各種原則將服務分離，創建多個服務、多個子系統。但是在眼前我們不必過多考慮這一點，大膽的去做吧。
為服務命名是我們要考慮的第一件事。大家不要忽略命名的重要性，為服務命名、為子系統命名、為領域對象、領域屬性、領域方法命名都是需要你認真對待的工作。經過一番思考後，我們認為“菜單”、“功能”、“用戶”、“角色”等事物是一個項目里幾乎必備的事物，是一切的源頭。所以我們引用門戶（Portal）這個詞作為服務的名稱，表示系統的入口，因此服務的全稱為PortalService。
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的教程，不可能完全演繹出真實項目迭代實施的每個細節，真要如此需要寫一本獨立的書籍了，也許以後我會抽時間去著作完成，但是在這裡我們會濃縮下項目實施的過程，提前告知各位正確的設計方式。從第5點開始後面的內容都是我們在實際工作中反覆提煉後得到的經驗與教訓。同樣的，大家在領域實戰的時候也會不可避免的犯設計上的錯誤，請無須擔心，大膽的去嘗試吧。
5） “許可權子系統”這個想法很好，從概念上講幾乎無懈可擊，但是從務實的角度來考慮會有些問題。如果我們為一個領域模型去創建一個子系統，這樣使用起來會比較麻煩。你試想一下，如果有“菜單子系統”、“角色子系統”、“許可權子系統”，當我們要在服務里創建一個角色時，這個服務必須引用“角色子系統”和“許可權子系統”才能完成工作，如果對象引用鏈比較多，你有可能需要引用的子系統數量遠超過預期。例如：用戶子系統會引用賬戶子系統、賬戶子系統會引用許可權子系統和角色子系統、用戶子系統還會引用地理位置子系統用以表示用戶所在地。這時候服務要使用用戶子系統就不得不多引用4個額外的項目，不僅麻煩也不利於維護更新。關於如何切斷引用鏈，讓子系統更加的獨立的話題後面會有更詳細的說明，這裡我們只用知道儘量不要為一個事物單獨創建子系統。
6） 因此，我們需要將內聚性比較高的事物合併在一個子系統里。找出與許可權模型緊密相聯的事物，再結合子系統應該提供的職責去綜合考慮是否將其他事物也納入到許可權子系統中。很明顯，角色是與許可權是密不可分的，角色不可能脫離許可權獨立存在，那樣的話角色就沒有意義了，我們使用角色的目的就是為了識別用戶身份，所謂“身份”在程式里的體現就是擁有哪些許可權。所以角色可以加入到許可權子系統中。那麼菜單呢？菜單的確依賴於許可權模型，但是這種依賴關係不代表菜單一定要和許可權在同一個子系統里。許可權子系統的主要職責是提供身份識別，這和菜單自身沒有任何關係。所以我們不必將菜單放入到許可權子系統里而是考慮稍後建立“菜單子系統”再由“菜單子系統”引用“許可權子系統”集成工作。
7） 明確了許可權、角色、菜單這三者所屬子系統的關係後，我們再來分析“用戶”應該被劃分至哪個子系統。首先，用戶這一事物足夠的模糊也足夠的複雜。說它模糊是因為在會議系統實施的前期我們還無法深刻的認識到用戶會有哪些具體的行為，我們僅知道用戶可以登錄系統，可以創建會議，與會人可以參加會議、會議主持人可以管理會議，但是這些僅僅只是整個項目需求的冰山一角，用戶可以參與的功能實在太多了。之所以說它複雜也正是因為用戶涉及到的功能眾多，為了向那些已知或未知的功能提供用戶不同維度的信息以便功能能正常的使用，我們有可能會頻繁的修改用戶模型。因此，用戶模型的可變化性是非常強的。如果把用戶模型放入許可權子系統，那麼一旦用戶模型改變就會引起許可權子系統的代碼改動。我們希望子系統儘可能的穩定，變化率足夠的小。另外，用戶只是使用角色、許可權等模型來證明自己的身份，角色、許可權並沒有依賴於用戶。換句話說，用戶模型引用了角色和許可權模型，但是角色和許可權模型並沒有引用用戶模型。用戶模型的任何變化都不會影響到許可權和角色模型的改變。所以，用戶和許可權子系統里其它模型的內聚性非常低，我們不應該把內聚性低的事物放在同一個程式集里。
8）綜上所述，”用戶”不應該放在許可權子系統里。我們可以像設計“菜單子系統”那樣建立“用戶子系統”，再由用戶子系統引用許可權子系統來工作。經過一番嘗試，我們發現這樣做雖然可以滿足需求，但是用戶子系統里會編寫大量關於“登錄”、“身份識別”等與許可權系統有關的代碼。因為在身份識別的時候，角色和許可權是不能繞過用戶的信息單獨提供給應用層使用的。使用者在登錄的時候還需要提供登錄名和密碼的信息交由用戶子系統判斷是否正確，然後再得到用戶的角色和許可權。所有與身份有關的請求都需要經過用戶子系統處理，而許可權子系統僅僅是提供了角色和許可權的數據而已，這樣用戶子系統過多的關註了許可權子系統要考慮的本職操作。如果這樣的話，我們還不如將用戶和角色、許可權放在同一個子系統里。而這又與我們之前的判斷相違背。那問題究竟出在哪裡呢？經過一番思考，我們認為缺少一個管理用戶身份的事物，這個事物提供了幫助用戶管理其身份和安全驗證的職責，它是用戶和許可權、角色之間的橋梁，我們為其命名為“賬號”。由賬號來分擔用戶這個事物在身份識別領域里的職責，用戶不必直接與角色、許可權打交道。所以我們把賬號、角色、許可權放在許可權子系統里，而把用戶放在用戶子系統里，用戶模型引用一個賬號模型，當需要識別身份的時候只用調用賬號來工作就可以了。
9） 最後，由於許可權子系統里的模型已經不單單隻有許可權了，所以我們為許可權子系統重命名為賬戶子系統（AccountSubsystem）。這樣第一個子系統的分析工作就已完成。再次聲明，因為篇幅原因我們濃縮了整個分析的過程。在實際工作的時候，我們是經過多次迭代和修正才完成了正確的系統劃分。在這個過程里，我們每次都以小的增量重構項目，每次重構的結果都不僅滿足用戶的需求而且越來越貼近事物的本質特征。這使得我們的程式越來越健壯，越來越容易維護，每次修改都很輕鬆，不會引起連鎖改動。大家在實際編碼的時候儘管大膽的去設計，多多鍛煉和積累自己的領域思想自然水到渠成，由量變到質變，你會發現自己的思維越來越敏捷，對錯誤的設計越來越敏感，思考問題的方式也異於常人，這時候就要恭喜你踏入了領域藝術家的境界，成為了一名真正的架構設計師。
下麵我們創建賬戶子系統（AccountSubsystem），賬戶子系統雖然被門戶服務使用，但是子系統本身是獨立於任何服務存在的。所以我們為賬戶子系統創建獨立的項目解決方案：
子系統的項目解決方案比服務的項目解決方案需要引用的程式集少很多。除瞭解決方案文件夾Framework里需要引用幾個CodeArt提供的類庫外，僅需額外創建一個AccountSubsystem的類庫項目，稍後我們會在這個程式集里創建領域模型。AccountSubsystemTest則是針對賬戶子系統的單元測試。
大家應該還記得，我們在門戶服務的解決方案里也添加了一個專門針對門戶服務的單元測試PortalServiceTest。嚴格的講，有效的自動化測試越多越好，這樣會給系統的維護帶來極大的好處。但是測試是有成本的，編寫測試用例、編碼實現測試用例都是需要時間完成的。所以在項目開發的過程中我們會更多的關註服務的測試，因為服務的測試會覆蓋到子系統的代碼，測試服務也會間接測試到子系統，一舉多得節約成本。只有當整個項目快結束的時候或者有空閑時間了，我們才會再來補充子系統的測試。
所以，當我們創建了AccountSubsystem項目解決方案並將代碼提交到代碼庫後，可以直接關閉該解決方案。打開PortalService，將AccountSubsystem子系統引用到PortalService的Subsystems解決方案文件夾里：
至此，為PortalService創建賬戶子系統的工作就完成了。在下個章節里我們開始進行領域模型的設計工作。
