一、簡介

領域驅動相信都不陌生,個人覺得是一個非常好的軟體開發思想,幫助我們充分發揮面向物件的思想,同時讓設計模式發揮他的魔力,同時讓我們的程式碼不再侷限於過程式的指令碼.所以,打算寫一個系列的關於領域驅動設計的隨筆,來提升自己的架構能力.本系列的隨筆參考於領域驅動設計：軟體核心複雜性應對之道這本書,我會對上面的內容做一個整理歸納,從C#程式設計師的角度,去總結一些觀點。廢話不多說,here wo go!

二、基本知識點

1、什麼是領域

日常開發種我們的軟體都是為了滿足使用者的需求,或者說幫助他們解決某一類的問題。所以這個時候使用者下載我們設計的軟體,並把他們應用於某個主題區域,比如說網易雲音樂,解決的就是使用者線上聽歌的問題,所以使用者自然會把他歸結到線上音樂的主題區域, 此時,根據領域驅動設計的理念,這個主題區域就是領域.

2、領域的應用範圍

領域的範圍應用很廣,歸納之,主要包含物質世界和虛擬世界,如一個點餐程式,他的領域包含餐廳和收銀員等,這一類的都涉及物質世界。再如一個程式碼管理工具,他的領域則是程式碼,這一類涉及虛擬的世界.

3、傳統開發模式的問題,以及領域模型的誕生

為了構建一個某個領域高價值的軟體,開發團隊不得不去研究該領域下的所有知識,所需的知識是非常龐大的.而且複雜程度也非常的高,所以這個時候引入領域模型是非常必要的,因為領域模型對所有的知識進行有選擇的簡化和結構化,幫助我們識別出領域種的核心關鍵點.通過領域模型能幫助我們有效的消化知識,讓知識看起來很流暢,而不是像傳統文件那樣,一團亂麻!

4、領域模型的概念和作用

領域模型不單單是一個模型圖,而是一種思想,是一種經過嚴格組織並精心選擇的抽象知識,直擊領域的核心.忽略掉領域的部分細節.模型圖可以表達一種模型,作為程式設計師,一段好的程式碼也可以,好的文件也可以.所以知識選擇得當領域模型可以是任何知識的載體,單前提是該載體必須是經過嚴格組織並精心選擇的抽象知識.

重點:

建立領域模型並非原封不動建立一個符合"現實"的模型,這是不可能的,如果讓你開發一個關於生活的軟體,你可能將生活種的每個細節都通過程式碼展現出來,即使強如BAT,也做不到.所以建立領域模型更像是拍一部紀錄片,將生活中最美好的部分展現給觀眾,軟體也是如此,通過建模將軟體和核心點抽象出來(形成領域模型),然後將所有的模型通過演算法連線起來,寫成軟體給使用者使用.

5、領域模型在領域驅動設計中的作用

(1)、模型和設計的相互影響

我們通過對領域知識的抽象形成一個個領域模型,此時的模型和實現是緊密結合的,如果通過程式碼將模型轉換成一個有用的產品,那麼此時後續的開發人員就能通過模型很好的理解程式碼為什麼要這樣實現.而不用通過溝通或者檢視複雜的文件去理解.而且後續的修改擴充套件也很方便,只需圍繞這個模型即可.通過對模型的把控,就能驗證後續的需求實現的可能性,以及當前的模型存在的一些問題等等.

(2)、模型的重要性

一旦業務形成可用的領域模型,那麼他就會變成團隊的交流的中樞,後續的修改,團隊都會圍繞該模型展開.這時候模型就變成了一種交流的語言.所以,後續我們就可以通過語言來對他進一步的擴充套件.這是我們天生就具有的本領.

三、消化知識

1、如何構建最初的模型

關於消化知識,其實就是抽象領域知識的過程,這裡舉個列子,假設需要設計一個.Net使用者登陸系統,這裡假設我之前沒有做過相關的功能,這個時候恰好有一個領域專家配合我.那麼下面我們就開始進行頭腦風暴.開始我想讓專家告訴我想通過C#程式碼達成什麼。但是他完全沒有C#編碼經驗.剛開始很艱難,但是我們得到了最基本的兩個元素如下:

接著我們繼續討論,他告訴我,使用者必須輸入使用者名稱和密碼才能登陸系統!而且使用者必須註冊到伺服器,然後登陸的時候驗證使用者名稱和密碼伺服器中時候存在,存在則登陸成功,才能訪問伺服器上的資源.所以我修改了模型如下:

 接著我們繼續討論,他告訴要加一個驗證碼和限制登陸次數為5次的功能,防止機器程式強行登陸.所以我繼續修改模型,這裡就不加圖了.

就這樣,我們繼續討論,隨著我對領域知識加深,不斷的修改模型,最終形成了初期的領域模型,如下:

這個時候,如果專家提出了新的需求,我就判斷當前模型是否能滿足他提出的需求,如果不滿足,就修改模型。在精華模型的同時,程式碼也隨之演進.最終形成了一個高擴充套件高可用的使用者登陸模組.

2、有效建模的要素

(1)、模型和實現的繫結

上面的模型圖和實現深度繫結雖然很簡陋,但他在模型和實現之間建立了早期的連結,而且在後續的迭代中我們將一直維護該原型.

(2)、獲得了一種基於模型的語言

最初,專家不得不向我解釋使用者登陸領域的問題,而我也必須向他解釋C#類的概念,隨著模組的擴充套件,我們都能使用模型中的術語,並將他們組織為符合模型的語句.那麼後續的開發中我們就不需要解釋各自領域的專業術語.

(3)、提煉模型

在模型日趨完善的過程中,重要的概念不斷地被加到模型中,不重要地概念則被剔除.當一個不需要的概念和一個需要的概念產生關聯式,則將需要的概念提取到一個新的模型中,不需要的刪除掉.

(4)、頭腦風暴的重要性

語言和操作,加上頭腦風暴,使我們的模型茁壯的生長,當團隊走查場景時,口頭表達就可以測試模型的有效性,在這個過程中,基於模型的語言提供了很大的幫助,能幫助我們不斷地訓練模型,檢測模型地可用性,以及一段地擴充套件模型,最後我們將得到一個很有價值的模型.

3、傳統瀑布方法的缺點

傳統瀑布方法,業務專家和分析員對業務進行分析,並形成抽象並傳遞給程式設計師,這個過程分析員全權負責建立模型,這個模型只是參考業務專家的意見,並沒有讓程式設計師參與,這樣久而久之,只有業務專家和分析員精通業務知識,知識只是朝一個方向流動,沒有形成積累.如果這個過程讓程式設計師參與,那麼好的程式設計師,自然而然會開發出一個可以完成更多工作的模型.

但是如果這個過程只讓程式設計師參與,那麼得出得模型是非常幼稚得.所以如果這個過程如果讓兩者都參與到其中,那麼得出得模型是非常優質得.所以這就是領域驅動得優勢.