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

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

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

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

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

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

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

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

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

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

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

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

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

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

下面，談談我的想法。

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

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

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

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

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

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

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

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

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

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

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

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

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

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