歡迎光臨
每天分享高質量文章

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

回顧

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

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

第一部分  運用領域模型

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

第一章 消化知識

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

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

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

模型在不斷改進的同時,也稱為組織專案信息的工具。模型聚焦於需求分析。它與編程和設計緊密交互。

知識豐富的設計

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

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

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

經過以上對比,你會發現設計樣式有它自己的適用場景,不要隨便套用。第二點設計的模型和代碼實現一致。

深層模型

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

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

第二章 交流與語言的使用

通用語言

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

書面設計文件

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

文件和圖

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

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

本篇結束,謝謝觀看。

原文地址:https://www.cnblogs.com/fancunwei/p/9535982.html

赞(0)

分享創造快樂