目錄

• 領域驅動設計-運用領域模型-系結模型和實作
  • MODEL-DRIVEN DESIGN
  • 建模范式和工具支持
  • 為什么模型對用戶至關重要
  • HANDS-ON MODELER

領域驅動設計-運用領域模型-系結模型和實作

聰明的專案組成員花費了幾個月的時間進行仔細的研究并且開發出了詳盡的領域模型（類圖），然而對類圖研究不能讓我深入地了解該應用程式的代碼和設計，這讓我備感困擾，當開發人員開始實作應用程式時，他們很快就發現，盡管分析人員說得頭頭是道，他們依然無法將這種錯綜復雜的關系轉換成可存盤、可檢索的且具有事務完整性的單元，

由于模型是“正確的”，這是經過技術分析人員和業務專家大量協作才得到的結果，因此開發人員得出這樣的結論：無法把基于概念的物件作為設計的基礎，于是他們開始進行專門針對程式開發的設計，他們的設計確實用了一些原有模型中類和屬性的名稱進行資料存盤，但這種設計并不是建立在任何已有模型的基礎上的，

這個專案雖然建立了領域模型，但是如果模型不能直接幫助開發可運行的軟體，那么這種紙上談兵的模型又有什么意義呢？

領域驅動設計要求模型不僅能夠指導早期的分析作業，還應該成為設計的基礎，這種設計方法對于代碼的撰寫有著重要的意義，不太明顯的一點就是：領域驅動設計要求一種不同的建模方法

個人理解：建了模型可以更快了解所需知識，可又不能轉化成程式代碼實作，到底要怎樣？我也搞不懂了，反正覺得好復雜

MODEL-DRIVEN DESIGN

嚴格按斬訓礎模型來撰寫代碼，能夠使代碼更好地表達設計含義，并且使模型與實際的系統相契合，

那些壓根兒就沒有領域模型的專案，僅僅通過撰寫代碼來實作一個又一個的功能，它們無法利用前兩章所討論的知識消化和溝通所帶來的好處，如果涉及復雜的領域就會使專案舉步維艱，

另一方面，許多復雜專案確實在嘗試使用某種形式的領域模型，但是并沒有把代碼的撰寫與模型緊密聯系起來，這些專案所設計的模型，在專案初期還可能用來做一些探索作業，但是隨著專案的進展，這些模型與專案漸行漸遠，甚至還會起誤導作用，所有在模型上花費的精力都無法保證程式設計的正確性，因為模型和設計是不同的，

模型和程式設計之間的聯系可能在很多情況下被破壞，但是二者的這種分離往往是有意而為之的，很多設計方法都提倡使用完全脫離于程式設計的分析模型，并且通常這二者是由不同的人員開發的，之所以稱其為分析模型，是因為它是對業務領域進行分析的結果，它在組織業務領域中的概念時，完全不去考慮自己在軟體系統中將會起到的作用，分析模型僅僅是理解工具，人們認為把它與程式實作聯系在一起無異于攪渾一池清水，隨后的程式設計與分析模型之間可能僅僅保持一種松散的對應關系，在創建分析模型時并沒有考慮程式設計的問題，因此分析模型很有可能無法滿足程式設計的需求，

這種分析中會有一些知識消化的程序，但是在編碼開始后，如果開發人員不得不重新對設計進行抽象，那么大部分的領域知識就會被丟棄，如此一來，就不能保證在新的程式設計中還能保留或者重現分析人員所獲得的并且嵌入在模型中的領域知識，到了這一步，要維護程式設計和松散連接的模型之間的對應關系就很不合算了，

個人理解：業務畫的模型圖，在技術人員看來，需要進行翻譯成程式模型圖（流程圖），這樣，兩個模型之間肯定會有不同的部分，會有一些領域知識舍棄，那這兩個模型對應關系需要來維護，無疑增加了復雜度，

無論是什么原因，軟體的設計如果缺乏概念，那么軟體充其量不過是一種機械化的產品——只實作有用的功能卻無法解釋操作的原因，

如果整個程式設計或者其核心部分沒有與領域模型相對應，那么這個模型就是沒有價值的，軟體的正確性也值得懷疑，同時，模型和設計功能之間過于復雜的對應關系也是難于理解的，在實際專案中，當設計改變時也無法維護這種關系，若分析與和設計之間產生嚴重分歧，那么在分析和設計活動中所獲得的知識就無法彼此共享，

個人理解：上面的我也沒看懂，反正就是說業務涉及的模型和技術流程圖是有很大不同，原因是思考方式不同，這樣很難對應維護，

MODEL-DRIVEN DESIGN（模型驅動設計）不再將分析模型和程式設計分離開，而是尋求一種能夠滿足這兩方面需求的單一模型，不考慮純粹的技術問題，程式設計中的每個物件都反映了模型中所描述的相應概念，這就要求我們以更高的標準來選擇模型，因為它必須同時滿足兩種完全不同的目標，

有很多方法可以對領域進行抽象，也有很多種設計可以解決應用程式的問題，因此，系結模型和程式設計是切實可行的，但是這種系結不能夠因為技術考慮而削弱分析的功能，我們也不能接受那些只反映了領域概念卻舍棄了軟體設計原則的拙劣設計，模型和設計的系結需要的是在分析和程式設計階段都能發揮良好作用的模型，如果模型對于程式的實作來說顯得不太實用時，我們必須重新設計它，而如果模型無法忠實地描述領域的關鍵概念，也必須重新設計它，這樣，建模和程式設計就結合為一個統一的迭代開發程序，

將領域模型和程式設計緊密聯系在一起絕對是必要的，這也使得在眾多可選模型中選擇最適用的模型時，又多了一條選擇標準，它要求我們認真思考，并且通常會經過多次反復修改和重新構建的程序，但是通過這樣的程序可以得到與設計關聯的模型，

要想創建出能夠抓住主要問題并且幫助程式設計的單一模型并沒有說的那么容易，我們不可能隨手抓個模型就把它轉化成可使用的設計，只有經過精心設計的模型才能促成切實可行的實作，

個人理解：建模好難，不管怎么說，將業務和技術思維抽象成通用模型，本身就是學習成本，不是人人都能達到的，真的懷疑做模型的時間是不是還不如直接開發來的干脆，少搞這些虛頭巴腦的東西，老外對模型是真愛！

建模范式和工具支持

為了使MODEL-DRIVEN DESIGN發揮作用，一定要在可控范圍內嚴格保證模型與設計之間的一致性，要實作這種嚴格的一致性，必須要運用由軟體工具支持的建模范式，它可以在程式中直接創建模型中的對應概念，

面向物件編程之所以功能強大，是因為它基于建模范式，并且為模型構造提供了實作方式，從程式員的角度來看，物件真實存在于記憶體中，它們與其他物件相互聯系，它們被組織成類，并且通過訊息傳遞來完成相應的行為，許多開發人員只是得益于物件的技術能力——用其組織程式代碼，只有用代碼表達模型概念時，物件設計的真正突破之處才彰顯出來，Java和許多其他工具都允許創建直接反映概念物件模型的物件和關系，

沒看懂，直接忽略，設計不是一蹴而就的，我們需要反復研究領域知識，不斷重構模型，才能將領域中重要的概念提煉成簡單而清晰的模型，

為什么模型對用戶至關重要

從理論上講，也許你可以向用戶展示任何一種系統視圖，而不管底層如何實作，但實際上，系統上下層結構的不匹配輕則導致誤解，重則產生bug，

如果程式設計基于一個能夠反映出用戶和領域專家所關心的基本問題的模型，那么與其他設計方式相比，這種設計可以將其主旨更明確地展示給用戶，讓用戶了解模型，將使他們有更多機會挖掘軟體的潛能，也能使軟體的行為合乎情理、前后一致，

個人理解：這里說了很多理論，其實就是一點，如果模型做的不好，直接導致做出來的東西會復雜難用，用戶難以接受，

HANDS-ON MODELER

人們總是把軟體開發比喻成制造業，這個比喻的一個推論是：經驗豐富的工程師做設計作業，而技能水平較低的勞動力負責組裝產品，這種做法使許多專案陷入困境，原因很簡單——軟體開發就是設計，雖然開發團隊中的每個成員都有自己的職責，但是將分析、建模、設計和編程作業過度分離會對MODEL-DRIVEN DESIGN產生不良影響，我曾經在一個專案中負責協調不同的應用程式開發團隊，幫助開發可以驅動程式設計的領域模型，但是管理層認為建模人員就應該只負責建模作業，撰寫代碼就是在浪費這種技能，于是他們不準我撰寫代碼或者與程式員討論細節問題，

個人理解：現在軟體工程就是分了很多流程：調研-需求評審-概要設計-詳細設計-系統開發-測驗-上線-維護，難道每個人負責自己的模塊不好嗎？很多對日外包就是拿日本人設計好的偽代碼和流程圖，直接用程式翻譯出來，難道自己的理解有問題了？

開始專案進展的還算順利，我和領域專家以及各團隊的開發負責人共同作業，消化領域知識并提煉出了一個不錯的核心模型，但是該模型卻從來沒有派上用場，原因有兩個，

其一，模型的一些意圖在其傳遞程序中丟失了，模型的整體效果受細節的影響很大這些細節問題并不是總能在UML圖或者一般討論中遇到的，如果我能擼起袖子，直接與開發人員共同作業，提供一些參考代碼和近距離的技術支持，那么他們也許能夠理解模型中的抽象概念并據此進行開發，

第二個原因是模型與程式實作及技識訓相影響，而我無法直接獲得這種反饋，例如，程式實作程序中發現模型的某部分在我們的技術平臺上的作業效率極低，但是經過幾個月的時間，我才一點一點獲得了關于這個問題的全部資訊，其實只需較少的改動就能解決這個問題，但是幾個月過去了，改不改已經不重要了，因為開發人員已經自行撰寫出了可以運行的軟體——完全脫離了模型的設計，在那些還在使用模型的地方，也僅僅是把它當作純粹的資料結構，開發人員不分好壞地把模型全盤否定，但是他們又有什么辦法呢？他們再也不愿意冒險任由呆在象牙塔里的架構師擺布了，

與其他專案一樣，這個專案的初始環境傾向于不讓建模人員參與太多的程式實作，對于該專案所使用的大部分技術，我都有著大量的實踐經驗，在做建模作業之前，我甚至曾經在同類專案中領導過一個小的開發團隊，所以我對專案開發程序和編程環境非常熟悉，但是如果不讓建模人員參與程式實作，我就是有這些經歷也無法有效地作業，

如果撰寫代碼的人員認為自己沒必要對模型負責，或者不知道如何讓模型為應用程式服務，那么這個模型就和程式沒有任何關聯，如果開發人員沒有意識到改變代碼就意味著改變模型，那么他們對程式的重構不但不會增強模型的作用，反而還會削弱它的效果，同樣，如果建模人員不參與到程式實作的程序中，那么對程式實作的約束就沒有切身的感受，即使有，也會很快忘記，MODEL-DRIVEN DESIGN的兩個基本要素（即模型要支持有效的實作并抽象出關鍵的領域知識）已經失去了一個，最終模型將變得不再實用，最后一點，如果分工阻斷了設計人員與開發人員之間的協作，使他們無法轉達實作MODEL-DRIVEN DESIGN的種種細節，那么經驗豐富的設計人員則不能將自己的知識和技術傳遞給開發人員，

HANDS-ON MODELER（親身實踐的建模者）并不意味著團隊成員不能有自己的專業角色，包括極限編程在內的每一種敏捷程序都會給團隊成員分配角色，其他非正式的專業角色也會自然而然地產生，但是如果把MODEL-DRIVEN DESIGN中密切相關的建模和實作這兩個程序分離開，則會產生問題，

整體設計的有效性有幾個非常敏感的影響因素——那就是細粒度的設計和實作決策的質量和一致性，在MODEL-DRIVEN DESIGN中，代碼是模型的表達，改變某段代碼就改變了相應的模型，程式員就是建模人員，無論他們是否喜歡，所以在開始專案時，應該讓程式員完成出色的建模作業，

任何參與建模的技術人員，不管在專案中的主要職責是什么，都必須花時間了解代碼，任何負責修改代碼的人員則必須學會用代碼來表達模型，每一個開發人員都必須不同程度地參與模型討論并且與領域專家保持聯系，參與不同作業的人都必須有意識地通過UBIQUITOUS LANGUAGE與接觸代碼的人及時交換關于模型的想法，

將建模和編程程序完全分離是行不通的，然而大型專案依然需要技術負責人來協調高層次的設計和建模，并幫助做出最困難或最關鍵的決策，

個人理解：每個人都要會一點建模，就算是開發人員，也要參與其中，就算是業務人員，也要稍微懂些代碼，每個人要有自己的專業能力，同時也要全面發展，了解整個流程的作業內容，一句話：可以不做，但是不能不會，突然有一個需要程式員去做需求或者詳細設計，也要能扛下來這個任務，目的不是讓一個人做多個任務，擔任軟體開發流程中的多個職責，而是懂得一些后大家溝通建模沒有障礙，會相互理解，

標籤：領域驅動設計

上一篇：二 領域驅動設計-運用領域模型-交流與語言的使用

下一篇：模型驅動設計的構造塊