解構領域驅動設計

前面道理講的很清楚，系統組成部分相比整個系統是簡單的，但是各部分之間相互作用，則產生了複雜系統。 所以讓組成部分相對獨立，有序協作，就直接會大大減少系統複雜度。 規模是影響理解力的關鍵要素，結構也對複雜度有着重要影響，這其實體現了架構設計的重要性。 DDD就是這樣一個方法論，指導如何 合理的 劃分組成部分邊界，控制組成部分大小合適的規模 以及 它提供的能力，加上各部分之間的協作關係。 它關注的不僅僅是上層的結構設計，也關注污濁不堪的細節層面， 強調架構演進性，抵抗技術債。 事實就是這樣，架構設計不只是大的結構上的，關注組成部分中具體的模型和關係同樣關鍵。 系統之美中也有一句話， 一個系統中包含很多子系統，而它又存在於更大的系統中，這提示我們應以系統視角看待任何部分，系統就像是套娃，大系統小系統小小系統之間就像是在搭積木。 領域 子域 聚合 聚合內的模型 都是我們面對的“系統”，那麼把每個“系統”處理到何種程度的規模，它們之間是何種協作、通信， 正是DDD所講的。 最後各種思想都有它的侷限性，辯證思考他們的優點和缺點，以及自己需要做到什麼程度，太追求極致可能帶來的又是邊際成本遞增。 架構設計的終點，是基於多種方法論和經驗的辯證和平衡的藝術。 PS：推薦給的不只是這本書，更多的是DDD的思想，多年前還在上學時看Eric原著的時候看目錄都看不懂，還在奢望讀英文原版，最後看了幾頁 和 幾篇文章，毛也沒理解到。後來還花1500（可惜了….）元買了一個人的視頻課，上來第一節就講要如何寫，現在回想真的可笑。 後來逐漸遇到一些複雜系統，纔算是明白了一點，Eric和Vaughn解決的是什麼問題。

感覺讀一遍根本就沒用，起碼得三遍起。內容沒的說，全部是幹活，只不過需要一個特別煎熬的“啃”的過程，這也說明了領域驅動設計的學習取消是多麼陡峭。有決心有毅力的小夥伴百分之百推薦把這本書當作啓蒙、提高以及應用當中的工具書。

粗略的翻看了一遍，總體感覺邏輯還是比較完整的，圍繞着領域驅動設計統一過程進行闡述，知識比較多，內容比較廣，融入了作者在軟件系統架構方面的豐富經驗，並且有理論有樣例，實操性也比較好，在實踐領域驅動設計時可以作爲一本不錯的參考書。

項目使用過領域驅動設計，但不知所以然。 本書雖然概念較多，但也有獨到之處，選擇性的閱讀了一些內容，😁學到了東西。

有實操性，對領域驅動設計有了結構性瞭解。

廢話連篇，DDD就能表達的內容，全篇“領域驅動設計”光這六個字估計得佔了1w字。各種套用概念，使用“解空間”，想抽象包裝的高大上一些，但反而覺得可笑，如果真的懂，就做的徹底點，把技術設計問題轉化爲數學上的優化問題，論證說明爲什麼領域設計方法，在這個優化問題上是一個合適的方法。能這麼組織也可以，但除了套用概念沒其它實用的內容

《解構領域驅動設計》這書強烈推薦，作者深入理解了領域驅動設計的原理，並直言不諱的指出領域驅動設計有四大不足：領域驅動設計缺乏規範的統一過程，領域驅動設計缺乏與之匹配的需求管理體系，領域驅動設計缺乏規範化的、具有指導意義的架構體系，領域驅動設計的領域建模方法缺乏固化的指導方法。在提出問題後，作者在領域驅動設計的基礎上提煉出一套流程化、可落實的操作流程，讓原本抽象的，依賴經驗的領域驅動設計不再那麼晦澀難懂，而是按照領域驅動設計統一過程，新手也有參考的步驟的範例，這樣便於領域驅動設計的落地。 這是一本軟件設計的書，但作者在寫作時，並不單純的侷限於軟件開發，在寫作的過程中，嚐嚐提供了發散性思維，值得我們深思，作者的所表的思想並比僅僅適用軟件開發，更多的事提供一種解決問題的方法論，一種對世間萬物的理解的哲學之道。

讀《解構領域驅動設計》，讓我跳出對 DDD 概念的表層認知，真正理解領域驅動設計並非一堆模式的堆砌，而是一套面向複雜業務的思考方式。書中對戰略設計、戰術建模的拆解，理清了限界上下文、聚合、統一語言的內在聯繫，糾正了我把 DDD 簡單等同於微服務的誤區。 很多項目問題，根源不在於技術實現，而是業務理解不到位、邊界劃分模糊。這本書兼顧理論與落地，告訴我們建模要貼合真實業務，不能機械套用模板。結合日常開發，我意識到前期做好領域梳理，能夠減少後期大量的業務返工。DDD 重在思維轉變，後續工作中我會嘗試用領域視角分析需求，平衡業務複雜度與技術實現。

25年閱讀完的技術專業書，值得推薦。 本書深入淺出地介紹了領域驅動設計(ddd)，重點有三: 1.why？引入領域驅動設計的目的是爲了降低業務複雜度和團隊溝通成本。 2.what？領域驅動設計，是以業務爲核心，通過構建具有業務邏輯的領域模型，以聚合，實體，值對象，消息契約，事件等關鍵節點，實現業務邏輯和技術邏輯分離的一種設計理念。 3.how?如何使用ddd，核心在於在項目實踐中梳理出業務邊界，隔離變與不變，使用充血模型替代貧血模型，等等，不一而足。 目前正在初步嘗試ddd，同時也謹記不能過度設計，在探索一種適合自己的開發範式。 雷

之前也讀過Eric的DDD，相較而言，這本書在對DDD的精細度和落地指導上做得更爲具體和系統。提出了“領域驅動設計統一過程”來指導DDD的具體實踐。 不過，書中也提到DDD是爲了控制軟件複雜度，但我感覺這套體系本身似乎也夠複雜了（結合書中對複雜度的定義：規模、結構、變化）。有幾個問題可惜沒有看到解答：是不是張逸這套方法論本質上將原本代碼實現中的複雜度轉移到了分析與設計階段？如果真是這樣，那麼這種複雜度轉移是否真的有意義？設計和分析的複雜度是否應該取代或優先於代碼實現的複雜度？如果存在DDD的使用範圍，那這個範圍的尺度是多大呢？