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