基于抽象的分層結構

Author：Anders小明

（2008-1-8更新）

前言：現有已知的分層結構基本上是基于技術結構的，無論是SpringSide（早的還有AppFuse）還是DDD提出的分層結構，都是基于職責角色劃分的。然而對于復雜的企業應用系統來說，僅僅以該緯度來劃分，是無法完成邏輯的分解的。我們還需要基于抽象的分層緯度。

基于抽象的分層結構
眾所周知：抽象是有排列的。進一步，在企業應用中，抽象的排列也是分層的；與此同時，抽象還是分模塊的，定義良好的交互接口，保持抽象間交互的穩定是及其重要的。

抽象層次的劃分是以業務概念劃分為依據的，以保險系統為例，可以把抽象層次分為三層：保險其自身核心業務概念——核心抽象層，又受國家監管規則——國家抽象層，以及公司自身規則——公司抽象層。

如果說對于抽象的層次劃分是縱向分類的話，那么模塊劃分就是橫向分類。模塊劃分是較為常見的，不再舉例。

對于抽象分層的，需要進一步的說明。如下為一個三層抽象的說明。白色為核心抽象層，水綠色為擴展抽象層，天藍色為特定抽象層。

對于抽象的分層，是符合人的思維邏輯的一種思考問題的方式，由簡單到復雜。注意到白色為代表的核心抽象其覆蓋面積是最小的，其邊界也是最小。然后是擴展抽象，再然后是特定抽象。對抽象分層的第二個好處是：可以迭代地螺旋前進。

先看看核心抽象層：核心抽象層必須足夠精巧而且穩定，因為他們是系統的最基本和最簡單的結構！同時核心抽象層是可以運行的！他們的抽象和默認實現在全系統的地位——類似于數學系統的中的0和1！而具有復雜變化的擴展層和特定層就類似于數學中的2和3，然而，我們都知道，在數學中，0和1才是最重要的，沒有0和1，數學系統是無法構建的。

對于抽象層次而言，面臨的問題是如何保護抽象層次的邊界，確保上層抽象的變更不會引起下次抽象的具體變更。這就要求下層抽象在擴展實現時委派邏輯到擴展抽象層中新的接口和抽象。這樣即保證了核心抽象的基本語義，由保護了核心抽象的邊界。

系統必須支持核心抽象層為下層抽象留下擴展的空間，基本的手段是通過暴露Factory，將擴展實現注入到核心抽象層次中；除了擴展，系統還需要支持替換（override），也是要暴露核心層的Factory，將替換實現注入到系統中；現在很多基于類似Spring的系統，可以借助Spring的Bean Override機制完成；

這樣的抽象層次由于本身是完備和有邊界的，他們可以被獨立地維護。

在全系統下的核心抽象層是0和1，然而在考慮擴展抽象層時，該層就成為其特定抽象層的0和1，我們需要像構建核心抽象層一樣來構建該層，以保持本身的完備性，邊界以及擴展性。

如此反復迭代，隨著系統外圍的邊界不斷擴大，全系統所提供功能也越來越多，擴展點也就越來越多，系統支持的動態特性也越來越多！