重新解讀DDD領域驅動設計(一)

回顧

十年前，還未踏入某校時，便聽聞某學長一畢業就入職北京某公司，月薪過萬。對于一個名不見經傳的國小院，一畢業能拿到這個薪水還是非常厲害的。聽聞他學生期間參與開發了一款股票軟體，股票那時正迎來一波瘋漲。時也運也。我那時心裡就想，隻會軟體也行不通吧，至少要熟悉股票規則。在還未踏入程式設計大門時，我就清楚的認識了軟體服務于業務的本質。

      等剛開始工作時，從事些較簡單的工作，也是需要和使用人員讨論需求，文檔編寫和開發實作。性質偏向于公司内部财務人員或業務人員管理用的子系統。也許厭煩了寫的代碼用的人太少，于是轉移到了網際網路類型的公司。在日益複雜的業務與軟體規模下，以前用的熟練的三闆斧漸漸适應不了，知識庫需要更新了。結合以前的工作實踐，按自己的了解，重新解讀下領域驅動設計。

第一部分  運用領域模型

按照一個系統的開發步驟，除了前期招标，合同，預算，人員規劃等其他項目管理的範疇外，真正執行到系統部分是從溝通業務需求開始的。

第一章 消化知識

幾年前我們要做一個院系資産管理系統，最開始了解的有人申請，管理者稽核購買，分發扣庫存的邏輯。實際讨論下來之後，分為很多流程。如裝置提申請，教務處審批，院系審批，送出财務核賬。又涉及到固定資産折舊，退貨流程，又要财務核對。又有家具的申請與退貨等其他。還有定期的報表功能。基于我們開發人員和校方人員，都對資産稽核，退貨，對賬流程都有一定熟悉度，是以溝通下來業務大架構還算順利。我了解為我們在溝通業務的過程中，有了相似的認識，并在磨合過程中，修煉完善。DDD一書中，以PCB電路闆軟體工具為開篇，講述了PCB專家和開發人員溝通中從最開始的很難溝通，到最後依據流程圖及PCB元件執行邏輯完成了語言上的溝通統一。很幸運，我們大部分的業務并沒有如文中跨度那麼大。

在溝通的過程中，業務專家需要了解共同建構的業務模型，開發人員也要依據業務模型來勾思大概實作邏輯。就比如裝置申請，家具申請,XX申請;裝置退貨，資産退貨。這些有共同性，又有差異的流程，如何更好的抽象，來實作複用？如果單純開發人員自己抽象得到概念有可能是很幼稚的，開發出來的軟體隻能做基本工作，無法充分反映領域專家的思考方式。

領域專家和開發人員共同參與，一起來豐富抽象的模型。提煉模型，對于領域專家來說也是升華自己思考完善自己了解的過程。會更加注重概念的嚴謹性。

模型在不斷改進的同時，也稱為組織項目資訊的工具。模型聚焦于需求分析。它與程式設計和設計緊密互動。

知識豐富的設計

舉一個判斷是否合并賬号的邏輯。一個請求中的手機，郵箱賬号，根據賬号的是否驗證，以及資料庫中手機号郵箱的是否存在是否驗證來判斷是否合并賬号。産品列舉了81條合并規則。

我最開始想到了政策設計模式。根據各種狀态分析出主要的幾個政策來實作判斷。工作量相當複雜，而且易出錯。同僚建議了另外一種規則式的實踐。對比新賬号的狀态和篩選中的存在賬号狀态，形成一個規則，看這個規則符合那81條規則的哪一種。這樣代碼量指數級下降，也通用。而且其他人也更容易根據産品的文檔，直接看懂代碼。模型與實作一緻。

書中依據航線超賣為例，舉了兩個例子，一個是簡單的if超賣判斷，一個把超賣獨立成一個政策類來判斷超賣。并強調超賣在模型中不僅僅是一個簡單的判斷，而是一個讓所有人看到代碼都明白是一個獨特的政策。

經過以上對比，你會發現設計模式有它自己的适用場景，不要随便套用。第二點設計的模型和代碼實作一緻。

深層模型

說到太極，外是軟綿綿的一套動作。如果按軟體直接開發，實作出來的是錯的。因為陳家溝的領域專家們會告訴你太極每一招都是制人招。這個我信，如果有人喂招的話，分秒鐘被幹到地，對付普通人還是有效的。

這裡說的後續的制人招是深層模型，我們看到的慢騰騰的動作是表層。這樣說很容易了解。

第二章 交流與語言的使用

通用語言

領域專家和開發人員語言要一緻。将模型作為語言的支柱。確定團隊在内部的所有交流中以及代碼中堅持使用這種語言。

書面設計文檔

文檔應作為代碼和口頭交流的補充

文檔和圖

用圖來溝通交流，能促進頭腦風暴。但模型不是圖。            

本篇文章主要是應用自己親身經曆的案例來重新解讀領域驅動。

本篇結束，謝謝觀看。

作者：

從此啟程/範存威

出處：

http://www.cnblogs.com/fancunwei/

本文版權歸作者和部落格園共有，歡迎轉載，但未經作者同意必須保留此段聲明，且在文章頁面明顯位置給出原文連結。如文章對您有用，煩請點個推薦再走，感謝！ 本部落格新開通打賞，滑鼠移到右側打賞浮動處，即可賞部落客點零花錢，感謝您的支援！