DDD學習小結

一、引言

過去能夠去總結，將來能夠去期待，如今得認真實行。——特萊斯

整理總結、改正問題、認真實行、將來可期。

---

二、我理解的DDD

2.一、理解概念

一問起DDD，隨口而出的領域思想，各類先進各類好處，彷佛不用DDD就天理難容，這大概是度娘上大部分DDD文章所表述的。可是就我學習以來，想着如何把DDD實現到現實工做中，甚至於生活中的時候，感受到茫然、無從下手的感受。要實現DDD就必須先明白要作哪些準備。

使用某個技術天然要知道它是作什麼的，個人理解中DDD能夠分爲戰略和戰術兩個部分，戰略部分是使用DDD，戰術部分是實現DDD。

初學時在各論壇中看到的都是你們對DDD的推崇，便覺得DDD是最好的，這都是錯覺。DDD不是一種技術、不是一種技術、不是一種技術，重要的事情要說三遍，DDD是一種模式，在工做中那就是工做模式，是一種爲了解決某個問題的方法，是有必定原則須要去實踐的。

2.二、理解使用

張逸老師在《領域驅動戰略設計實踐》課程中說過：

面對客戶的業務需求，由領域專家與開發團隊展開充分的交流，通過需求分析與知識提煉，以得到清晰的問題域。經過對問題域進行分析和建模，識別限界上下文，利用它劃分相對獨立的領域，再經過上下文映射創建它們之間的關係，輔以分層架構與六邊形架構劃分系統的邏輯邊界與物理邊界，界定領域與技術之間的界限。以後，進入戰術設計階段，深刻到限界上下文內對領域進行建模，並以領域模型指導程序設計與編碼實現。若在實現過程當中，發現領域模型存在重複、錯位或缺失時，再進而對已有模型進行重構，甚至從新劃分限界上下文。

兩個不一樣階段的設計目標是保持一致的，它們是一個連貫的過程，彼此之間又相互指導與規範，並最終保證一個有效的領域模型。

提出問題域是很是重要的一個步驟，如何配合提出問題域。

這些都是能夠提煉問題域的方法，最重要的是理解意圖，不管是理解客戶意圖仍是理解隊友、理解領域專家的意圖。

---

三、學習體會

什麼時候使用DDD這種方式去解決問題，《領域驅動設計：軟件核心複雜性應對之道》這本書名就已經很好的解答了這個問題，在應對足夠複雜的軟件系統時，DDD也許會有者四兩撥千斤的做用，但咱們關注的應該是四兩撥千斤的這種思惟角度。

思惟是能夠借鑑的，因此思惟也是一種經驗，將別人的經驗用於實踐轉化爲本身的經驗，就能提高本身的思惟。