第一次接觸GoogleEarth，帶給我相當的震撼。你可以隨意轉動地球，通過縮放，看到不同層次的景象，這著實讓我吃驚，竟然可以這樣！手握鼠標，來回查看，有種作“上帝”的感覺，如果是實時的那就不得了了！相信很多人都有在上面尋找自己家的經歷。就拿我來說，首先轉到背面中國的位置，滑動滾輪，逐漸深圳的全貌顯露出來，西面是蛇口黃色的填海區，上面是深圳的綠肺塘朗山。繼續向下，黑灰色的廣深高速開始清晰可見，在我辨別清楚小區所在位置后，范圍進一步縮小，旁邊高級中學里紅色跑道包圍的足球場，看起來很規整，小區游泳池，也從一個小藍點逐漸露出了它的鋼琴造型。最后停放在小區里的轎車也顯露無遺。

  GoogleEarth提供了一個可伸縮的鳥瞰視角，生動的展示了我們所處地方的本來面貌。這不同于，我們每日看到的景象，也不同于我們曾經看到的地圖和地球儀。在DomainModel中，雖然沒有GoogleEarth for DomainModel的特殊版本。但我們可以采用類似的方法來查看我們的Model。

  在明確了DomainModel控制風格和演化規律后，我們還需要確定DomainModel中各部分的依賴和職責，才能得到整體觀感。

“從演化規律來看，要理解生命周期短者的觀點，必先理解生命周期長者的觀點”:)

我們先考察OO大師PeterCoad等的著作--Java Modeling In Color With Uml。
PeterCoad關于企業信息系統觀點的努力，首先在Object Models:Strategies,Patterns, and Application中得到表達，隨后，在Java Modeling In Color With Uml中，通過“Domain-Neutral Component”更系統的完善了他的構想。

“色彩迷”PeterCoad“四色論”觀點，簡單可表達為“特定領域構件，用四種領域中立，按照重要程度分配顏色的構件原型，建立模型。”

四種構件原型為：
“moment-interval”--代表領域中可長可短的業務交互。因其地位最重要，故用扎眼的粉紅色表示。
“party, place, or thing” --表示“moment-interval”中，涉及的實體。其地位在“description”之上，而在“role”之下，用舒服的綠色。
“role”-- 是指“moment-interval”中，"party, place, or thing"的參與方式。地位僅次于“moment-interval”，第二刺眼，黃色。
“description”-- 用來描述上述三者。最平靜，藍色。

關聯，一般是“moment-interval”----“role”----“party, place, or thing” ----“description”。但也存在其他關系。
另外PeterCoad在貢獻出領域中立構件原型“烤箱”的同時，還不忘贈送我們用它烹調出來的12套“特定領域構件”大餐，讓我們品嘗。

ColorUml確實給構建企業信息系統，帶了很多實用的指導。不過Domain.Driven.Design作者，領域驅動設計專家，Eric&Evans的觀點，也著實讓人入迷。

Eric&Evans在DDD中，明確提出了DomainModel職責層的概念。
“在深入了解一個領域之后，大模式開始顯現。一些領域具有自然的層次結構。某些概念和活動依賴于其他元素，而這些元素又出于不同的原因，以不同速率變化著，我們如何利用這種自然結構，使它變得更加明顯和有用呢？這種層次結構意味著分層，一種最成功的構架設計模式。”

“職責層最適合用分層模式中的“松散分層系統”來設計，它允許層，不光可以訪問它的直接下層，還可以訪問所有低于它的層。
因此：
仔細考慮模型中概念依賴的關系，它們的變更速率，以及導致領域各部分發生變化的來源。如果界定出了領域中的自然層次，那就把它們轉化成大的抽象職責。這些職責應當描述系統的高層目標和設計。重構模型，讓“領域對象”，“聚合”和“模塊”適合于它所放入的職責層”

具體分層由上到下是：
Decision ----決策支持，需要執行什么和設置何種策略？使用業務活動提供的當前信息和歷史信息，來分析決策，設置策略。
Policy ----策略，規則是什么？可以使用或約束低層行為。
Commitment----約束，承諾了什么？協議，合同。約束操作層，但其本身也是業務活動的結果。
Operation----操作，做什么？企業運營的核心業務活動
Potential----潛能，考慮能做什么？組織和其可用的資源。

在一般應用中，Operation層和Potential層可以放入大部分DomainObject。

比較上述兩者，可以找到相似之處，“party, place, or thing”構件原型同Potential層中包含的東西，極為類似。Operation難道不是“moment-interval”么？Commitment也是“moment-interval”的一種。“description”同“specification”類似。當然，也有不同之處，ColorUml沒有強調對象依賴關系的重要性。"role"在DDD中，沒有突出的位置。

下面，談談我的想法。

根據前面的討論和得到的規律，結合上面的論述。我們希望系統可以隨著業務的變化，而同步變化。如果，我們總是試圖遵循業務概念的依賴來搭建系統，那么，我們就能更直接的實現業務變化。如果，我們的系統就是按照業務的概念依賴關系，搭建起來的。那么，業務發生變化時，我能總能找到對應的變化點。按照概念依賴關系，我們知道那些對象可能會涉及到這種變化，那些對象根本不用考慮。

但正如前面提到的，業務概念的依賴關系，不會直接呈現在我們面前，我們必須采用“演化的觀點”，加以提取，不斷把基本概念和擴展概念進行分離。

入口，我選擇能體現企業存在意義的“核心業務交互”（理論上，可以從任何一個概念入手）。這類似于前面兩種方法的Operation/moment-interval。要理解加法，我們首先要對可以做加法的數有所了解。同樣道理，要理解“核心業務交互”，我們首先要理解參與交互的參與者。舉例來說，我們要理解生命周期較短的“購買商品”，就需要理解，誰買的？客戶，誰賣的？員工，購買的是什么？商品，在哪里購買的？地點，我們得到一些依賴關系：
購買商品-->客戶，購買商品-->員工，購買商品-->商品，購買商品-->地點。
要理解誰來扮演客戶或員工的角色么？如果需要的話，客戶-->參與者，員工-->參與者。
商品要分類么？是，商品-->商品目錄。商品的定價是多少？商品定價-->商品。在不同目錄里商品是同樣的定價么？否，集團購買的要便宜些，商品<--商品目錄定價-->商品目錄。商品目錄定價-->商品定價
商品有優惠策略么？有賣二送一，優惠策略-->購買商品。優惠策略有期限么？有，只在國慶節優惠，優惠策略-->日歷。

“核心業務交互”也可以是生命周期較長的概念，如“協議”。協議可以由一次較短的核心業務交互產生。如：電信中的購買協議，就是通過訂購活動產生的。也有把訂單視為協議的，但區分訂單和由此產生的購買協議，可以更好的對應實際訂單和跟隨訂單的協議書。按照“靜態依賴”規律，得到訂購-->購買協議。

“核心業務交互”可以很長，也可以很短。實際上，“核心業務交互”的壽命極限可以逼近參與角色，可以認為“客戶”也是一個大的“核心業務交互”，它通過“客戶開戶”這個瞬間“核心業務交互”而產生。

瞬間“核心業務交互”，比比皆是，通常在一個事務里處理的業務活動，都可以算作瞬間的“業務交互”。甚至，還存在，比事務還小的瞬間“業務交互”，例如：在一次“轉賬業務”中，可以包含一個“轉出業務”和一個“轉入業務”。

理解“業務交互”，是理解DomainModel的基礎。可以把“業務交互”看作是連接其他概念的紐帶，它本身會依賴一些基本元素，參與角色，資源，。在其上有依賴于它的協議、約束，策略和決策支持等。

我們來看一個“動態依賴”實例。
個人銀行業務：
通過“掛失業務”，創建一個“掛失協議”。掛失業務-->掛失協議(靜態依賴)
該“掛失協議”將影響到“取款業務”。掛失協議-->取款業務（動態依賴）

再看另外一個實例。
證券交易：
計算某筆“委托”的交易費用。費用策略-->委托（動態依賴）

可能，你已經注意到了這里有“核心業務交互”和“業務交互”，他們的區別在于，“核心業務交互”主要針對企業的外界涉眾而發生的“業務交互”，是企業的核心目標。此外，還存在為了達到核心目標而需要的，支持和管理的“業務交互”，如：“用戶授權”，簡單的“商品入庫”等等。需要注意的是，Eric Evans的職責層中的Operation應當理解為“核心業務交互”。而不是“業務交互”，考慮到Potential層產生員工的“員工開戶”，也是一個“業務交互”，就不難理解我的意思。

對于企業級應用，還可能存在的依賴有：
工作流-->業務交互
工作流策略-->工作流
項目管理-->業務交互
由于，它們可能會影響到整個“業務交互”，其基礎工作流引擎，基礎業務規則引擎，基礎項目管理構件，都需要放入底層的包中，在其之上擴展出的具體流程、規則和實際項目，將放入其依賴的具體業務交互的包里。

大體上，我接受Eric&Evans的觀點，從8000公里上空來看，最下層是最穩定的“潛能”、通用業務元素和通用引擎構件，在其之上是“核心業務交互”層，它將受到施加于其上的約束、承諾層的影響，在約束和承諾層之上，是策略層，策略通過考察“業務交互”和相關的約束承諾，按照已定義的規則行事，最后，決策層負責設置這些規則。

不過，正如Eric&Evans已表達的，把它看作一個指導，而不是約束。因為，就是在同一層中，同一個包中，也要考慮對象間的依賴關系，另外，領域的自然層次結構，并不一定完全遵循這種固定的劃分模式。

總之，我希望通過考察“核心業務交互”入手，建立一個帶有強烈“單向依賴”傾向的積木式DomainModel，得到一種簡單、明晰的優雅領域構架，它反映了領域的自然分層結構，因而，能從容應付業務當前和未來的發展變化。