接觸到DDD到現在已經有8個月份了，目前所維護的項目也是基於DDD的思想開發的，從一開始的無從下手，到現在遊刃有餘，學到不少東西，但是都是一些關鍵字和零散的知識，同時我也感受到了是因爲我對項目越來越熟悉，熟能生巧導致我現在在做需求的時候根本不用過多的去思考，就能很好的完成業務需求，我慢慢的意識到，學習DDD是非常有必要的。
在傳統的開發模式中，產品經理在跟業務專家溝通業務需求後，對其進行抽象並將結果通過口頭或者項目管理工具傳達到開發人員，開發人員根據產品經理傳遞的業務需求機械式地進行功能開發，這樣的模式使開發人員沒有真正的理解業務原理，開發出來的功能就很難達到業務方的要求，即使達到要求也難以應對未來的業務變化。
如果大家都運用DDD的思想進行開發，就能很好的傳遞業務知識，因爲DDD倡導開發人員、產品經理、領域專業一起討論、消化業務知識，徹底理解業務原理。
以下是我在學習DDD時做的一些筆記，並整理成思維導圖的形式，這樣就能很好的形成結構化的思維，希望能讓大家對DDD有一個更深的理解。
以下內容部分摘自 《領域驅動設計》和根據自己的理解整理而成。
1.1 有效建模的要素
模型和現實綁定
開發人員與產品經理在討論需求的時候，都會畫一些草圖和對草圖做一些文字說明，這其實就是最初的模型。最初的原型雖然簡陋，但它在模型與與實現之間建立了早期鏈接，而且在所有的後續迭代中我們一直在維護該鏈接。
建立一種基於模型的語言
- 起初領域專家不得不向開發人員解釋業務知識
- 開發人員也必需向領域專家解釋類圖的含義
- 隨着項目的進展，雙方都能夠使用模型中的術語，並將它們組織成符合模型結構的語句 ，而且可以無需翻譯就能互相理解要表達的意思
領域專家專注業務領域，開發人員專注開發，兩個不同領域的人在沒有形成統一語言的前提下是很難溝通的，比如電商領域專家拋出訂單履約的概念的時候，不得不在解釋什麼是訂單履約時，還得向開發人員翻譯裏面的各種名詞，如果領域專家和開發人員知識對等，就能互相理解各自要表達的意思。
開發一個蘊含豐富知識的模型
- 對象具有行和爲強制性的規定
- 模型並不僅僅是一種數據模型
- 模型應包含各種類型的知識
提煉模型
在模型日趨完整的過程中，要提煉模型，要將新的概念添加到模型中，同時將不再使用的或者不重要的概念從模型中移除。
頭腦風暴和實驗
- 語言和草圖，再加上頭腦風暴，將我們的討論變成“模型實驗室”在這些討論中可以演示、嘗試和判斷上百種變化
- 當團隊走查場景時，口頭表達本身就可以作爲所提議模型的可行性測試，因爲人們聽到口頭表達後，就能立即分辨出它是表達得清楚、簡潔還是表達的笨拙
1.2 消化知識
高效的領域建模人員是知識的消化者
建模人員需要從大量的信息中尋找有有的部分，然後不斷的嘗試各種信息組織方式，努力尋找對大量信息有意義的知識。
知識消化並非一項孤立的活動
- 一般由開發人員領導下，由開發人員與領域專家組成團隊來共同協作。
- 共同收集信息，並通過消化而將它們組織爲有用的形式
- 信息的原始資源來自領域專家頭腦中的知識、現有用戶、以及技術團隊在相關遺留系統或者同領域其他項目中積累的經驗
傳統瀑布模式的不足
業務專家與分析員（產品經理）進行討論，分析員消化理解這些業務知識後，對其進行抽象並將結果傳遞給程序員，再由程序員編寫軟件代碼。
- 這種方法完全沒有反饋（程序員沒有提供自己的想法）
- 分析員全權負責創建模型，但他們創建的模型只是基於業務專家的建議
- 分析員沒有向程序員學習，得不到早期版本的經驗
- 知識只是朝一個方向流動，不會累積
領域專家與開發人同一起消化理解模型的好處
在團隊所有成員一起消化理解模型的過程中，他們之間的交互也會發生變化。
- 領域模型的不斷精化迫使開發人員學習重要的業務原理，而不是機械地進行功能開發
- 領域專家被迫提煉自己已知道的重要知識的過程往往也是完善其自身理解的過程，而且他們會漸漸理解軟件項目所必需的概念嚴謹性。
小結
開發人員、分析員、領域專家，都應該將自己的知識輸入到模型中，這樣模型的組織更嚴密，抽象也更爲整潔。
模型不斷改進的同時 ，也成爲組織項目信息流的工具。模型聚焦於需求分析，它與編碼和設計緊密交互。
1.3 持續學習
當開始編寫軟件時，其實我們所知甚少
項目知識零散地分散在很多人和文檔中，其中夾雜着其他一些無用的信息，因此我們甚至不知道哪些知識是真正需要的知識。
看起來沒有什麼技術難度的領域很可能是一種錯覺 -- 我們並沒有意識到不知道的東西究竟有多少。這種無知往往會導致我們做出錯誤的判斷。
所有的項目都會丟失知識
- 已經學到了一些知識的人可能去幹別的事了
- 團隊由於重組而被拆散，這導致知識又被重新分散開
- 被外包出去的關鍵子系統可能只交回了代碼，而不會將知識傳遞回來
當使用典型的設計方法時，代碼和文檔不會以一種有用的形式表示出這些來之不易的知識。因此一但由於某些原因團隊成員沒有口頭傳遞知識，那麼知識就會丟失。
高效率的團隊需要有意識地積累知識，並持續學習
對於開發人員來說， 這意味着既要完善技術知識，也要培養一般的領域建模技巧。但這也包括認真學習他們正在正在從事的特定領域知識。
那些善於自學的團隊成員會成爲團隊的中堅力量，涉及最關鍵領域的開發任務要靠他們來攻克。這個核心團隊頭腦中積累的知識使他們成爲更高效的知識消化者。
1.4 知識豐富的設計
-
業務活動和規則如同所涉及的實體一樣，但是領域的核心，任何領域都有各種類別的概念。
-
知識消化所產生的模式，能夠反映出對知識的深層理解。
-
在模型發生改變的同時，開發人員對實現進行重構，以便反映出模型的變化，這樣，新知道就被合併到應用程序中了
1.5 深層模型
有用的模式很少停留在表面上， 隨着對領域和應用程序需求的理解逐步加深，我們往往會丟最初看起來很重要的表面元素，或者切換它們的角度。這時，一些開始不可能發現的巧妙抽象就會漸漸的浮出水面， 而它們恰恰切中問題的要害。