1、常規以類圖作為領域模型開發存在的問題

傳統型以技術為驅動的團隊,往往喜歡通過類圖來展示產品的模型,這樣的模型往往存N個物件,這些物件往往存在複雜的關聯,產品的創始人,可能能理解整個產品的架構思路,但是如果是新成員,想通過類圖去了解該產品,那幾乎是不可能的.往往最後還是需要領域專家進行溝通,在結合程式碼,才能理解這個產品。

而且假設這個類圖代表的領域模型是正確的,但是當團隊真正的去實現這個模型的時候,發現還是無法將這種錯綜複雜的模型轉換成可儲存可轉換的事務單元.這裡需要解釋下,因為前面的文章介紹了,最小化抽象領域的概念,這是領域驅動設計的必然要求,所以當我們結合類圖開發是,每次使用者的操作,都是以領域物件為單元的.但是因為類圖本身的缺陷,所以團隊還是無法理解裡面錯綜複雜的關係,特別是操作的領域物件和其它的領域物件有關聯時,難度會持續增加.

由於上述的基於類圖的領域模型是正確的,因為他是領域專家和開發人員共同討論的結果,而且最終形成了產品,但是他確不能指導正在進行的開發,而且新員工也無法通過該模型瞭解清楚整個產品的脈絡,所以這樣的模型是有問題的.但是他存在的意義會隨著時間和人事的變動而逐漸失去他存在的意義.

領域模型種類很多,他們的目的也各有不同,且領域驅動設計要求,模型不僅能夠指導前期的分析工作,而且還應該成為設計的基礎,我們的程式碼也必須是結合模型的.

很多設計方法提倡完全脫離於程式碼的分析模型,而開發人員也喜歡脫離於分析模型的類圖模型。領域專家在建立分析模型時可能不會考慮程式碼層面的可行性,舉個例子,之前爆紅網路的產品,手機殼變色的事件.哈哈!所以這種分析模型,可能不滿足程式設計的需求.而開發人員由於語言鴻溝或者分析模型的理解不徹底,導致編碼後核心的領域知識被丟棄的問題,而不得不對模型進行抽象,這個時候問題又產生了,新的模型種將會丟失領域專家嵌入在其中的領域知識.如果這個時候出現了新的領域核心點,但是開發人員覺得這於開發工作不相干而被捨棄,那麼這個時候分析模型會被漸漸的棄用,好了,這個時候產生的問題越來越多,最終導致專案失敗!

那麼我們需要一種方法來解決這個問題,讓我們的程式碼編寫能按照領域模型來逐步進行,而且隨著程式碼的編寫,模型能健康的生長.

3、領域模型採用的模式和解決方案

如果程式設計核心部分沒有和領域模型相對應,那麼這個模型沒有意義,同時如果模型和設計功能之間過於複雜,在軟體設計過程中,無法維護這個關係,那麼模型也是存在問題的,需要重新討論和設計(這個程式碼重構很想,當一個類很大,或者計算規則很複雜,那麼我們就需要對這個類進行重構,保持程式碼的間接易讀).

領域模型採用將分析模型和程式設計結合的方法,來解決這個問題,通過抽象出一個公共的模型同時滿足分析模型和程式設計的模型,來達成領域專家和開發人員承認的模型,這樣單一的領域模型和可用的.而不是同時存在兩個模型,各做各的事情.但是這個過程很艱難,需要長期的頭腦風暴,有些甚至不可能.但是必須得這麼做.否則隨著時間得推移,產品會漸行漸遠.

4、面嚮物件語言得優勢(C#)和Model-Driven Design(模型驅動設計)

C#之所以強大,因為他是面向物件並且基於建模範式,我們可以通過他來模擬現實種得場景和物件.像C這種面向過程式得語言,可能表現得比較無力.

5、模型驅動對於使用者的重要性

當我們設計系統時,要儘可能讓使用者得到最多的可配置模型,為什麼這麼說呢?打個比方,老式的IE瀏覽器,有一個收藏夾的功能,但是該功能有個缺陷,當用戶儲存網頁時,如果網址種包含非法字元如*/等,那麼IE瀏覽器會悄悄的將這個字元給幹掉,但是這樣做是非常不好的,這種資料的操作對使用者來說時不友好的.應用程式偷偷的修改使用者資料，是絕大多使用者無法接受的.這個時候如果IE能提供一個可配置的模型,讓使用者去決定過濾的規則,並適當的提示,並且讓使用者指定收藏夾的問題等等功能,這些都能通過模型來實現,IE通過該模型來做出正確的反應.這樣的模型才是友好的。而不是由IE自行處理,這樣使用者就變得非常的弱勢,那麼軟體的使用者可能隨之減少.

6、模型驅動對於開發人員的重要性

如果在專案開發種架構師只負責搭建核心驅動程式的模型,而不參與業務模型的搭建,任由手下的開發隨筆的去構建業務模型,那麼久而久之,整個產品可能可用,但是隨著人事變動,或者業務模組的複雜度增大,那麼最後整個領域模型可能也會因此變得不可用.所以這個過程架構師必須配合開發人員共同去構建業務領域模型,這會讓開發人員意識到改變業務領域模型,對整個模型是非常重要的,同時開發人員也能從架構師身上學到不少知識.