知識星球回顧
十年前，還未踏入某校時，便聽聞某學長一畢業就入職北京某公司，月薪過萬。對於一個名不見經傳的小學院，一畢業能拿到這個薪水還是非常厲害的。聽聞他學生期間參與開發了一款股票軟體，股票那時正迎來一波瘋漲。時也運也。我那時心裡就想，只會軟體也行不通吧，至少要熟悉股票規則。在還未踏入程式設計大門時，我就清楚的認識了軟體服務於業務的本質。
等剛開始工作時，從事些較簡單的工作，也是需要和使用人員討論需求，檔案編寫和開發實現。性質偏向於公司內部財務人員或業務人員管理用的子系統。也許厭煩了寫的程式碼用的人太少，於是轉移到了網際網路型別的公司。在日益複雜的業務與軟體規模下，以前用的熟練的三板斧漸漸適應不了，知識庫需要更新了。結合以前的工作實踐，按自己的理解，重新解讀下領域驅動設計。
第一部分 運用領域模型
按照一個系統的開發步驟，除了前期招標，合同，預算，人員規劃等其他專案管理的範疇外，真正執行到系統部分是從溝通業務需求開始的。
第一章 消化知識
幾年前我們要做一個院系資產管理系統，最開始理解的有人申請，管理員審核購買，分發扣庫存的邏輯。實際討論下來之後，分為很多流程。如裝置提申請，教務處審批，院系審批，提交財務核賬。又涉及到固定資產折舊，退貨流程，又要財務核對。又有傢具的申請與退貨等其他。還有定期的報表功能。基於我們開發人員和校方人員，都對資產審核，退貨，對賬流程都有一定熟悉度，所以溝通下來業務大框架還算順利。我理解為我們在溝通業務的過程中，有了相似的認識，併在磨合過程中，修煉完善。DDD一書中，以PCB電路板軟體工具為開篇，講述了PCB專家和開發人員溝通中從最開始的很難溝通，到最後依據流程圖及PCB元件執行邏輯完成了語言上的溝通統一。很幸運，我們大部分的業務並沒有如文中跨度那麼大。
在溝通的過程中，業務專家需要理解共同構建的業務模型，開發人員也要依據業務模型來勾思大概實現邏輯。就比如裝置申請，傢具申請,XX申請;裝置退貨，資產退貨。這些有共同性，又有差異的流程，如何更好的抽象，來實現復用？如果單純開發人員自己抽象得到概念有可能是很幼稚的，開發出來的軟體只能做基本工作，無法充分反映領域專家的思考方式。
領域專家和開發人員共同參與，一起來豐富抽象的模型。提煉模型，對於領域專家來說也是升華自己思考完善自己理解的過程。會更加註重概念的嚴謹性。
模型在不斷改進的同時，也稱為組織專案資訊的工具。模型聚焦於需求分析。它與程式設計和設計緊密互動。
知識豐富的設計
舉一個判斷是否合併賬號的邏輯。一個請求中的手機，郵箱賬號，根據賬號的是否驗證，以及資料庫中手機號郵箱的是否存在是否驗證來判斷是否合併賬號。產品列舉了81條合併規則。
我最開始想到了策略設計樣式。根據各種狀態分析出主要的幾個策略來實現判斷。工作量相當複雜，而且易出錯。同事建議了另外一種規則式的實踐。對比新賬號的狀態和篩選中的存在賬號狀態，形成一個規則，看這個規則符合那81條規則的哪一種。這樣程式碼量指數級下降，也通用。而且其他人也更容易根據產品的檔案，直接看懂程式碼。模型與實現一致。
書中依據航線超賣為例，舉了兩個例子，一個是簡單的if超賣判斷，一個把超賣獨立成一個策略類來判斷超賣。並強調超賣在模型中不僅僅是一個簡單的判斷，而是一個讓所有人看到程式碼都明白是一個獨特的策略。
經過以上對比，你會發現設計樣式有它自己的適用場景，不要隨便套用。第二點設計的模型和程式碼實現一致。
深層模型
說到太極，外是軟綿綿的一套動作。如果按軟體直接開發，實現出來的是錯的。因為陳家溝的領域專家們會告訴你太極每一招都是制人招。這個我信，如果有人喂招的話，分秒鐘被乾到地，對付普通人還是有效的。
這裡說的後續的制人招是深層模型，我們看到的慢騰騰的動作是表層。這樣說很容易理解。
第二章 交流與語言的使用
通用語言
領域專家和開發人員語言要一致。將模型作為語言的支柱。確保團隊在內部的所有交流中以及程式碼中堅持使用這種語言。
書面設計檔案
檔案應作為程式碼和口頭交流的補充
檔案和圖
用圖來溝通交流，能促進頭腦風暴。但模型不是圖。
本篇文章主要是應用自己親身經歷的案例來重新解讀領域驅動。
本篇結束，謝謝觀看。
原文地址：https://www.cnblogs.com/fancunwei/p/9535982.html
