為什么叫“戲說”呢？領域驅動設計出來的時候就有一種對于受眾的調戲，書是讀完了，您個人升華到了“看山非山，看水非水”的境界，再看一下落地代碼，搞不好會仰天長嘯：“這是我寫的？”，佛家講“空”，儒家講“仁”，領域驅動講“真”，真者，本質也，當您到了“真”的境界，就不會再與別人爭論“到底是java還是C#好”，也不會再糾結“我這個設計合不合理啊？”，很多東西自然而然的就出來了，
回顧歷史，領域驅動設計（Domain-Driven Design，簡稱DDD）大概源起于2004年，有個洋人叫Evic Evans出了本書叫《Domain-Driven Design : Tackling Complexity in the Heart of Software》（領域驅動設計：軟體核心復雜性應對之道）（其實我更關心副標題），全書大概包含兩部分：戰略設計、戰術設計，戰略方面關注如何將大系統劃小；戰術方面關注劃小后的軟體如何設計，隨著時間的推移，陸續有一些大家對領域驅動中的戰術部分進行了補充，比如“命令查詢分離架構（CQRS）”、“事件溯源（ES）”等，
從2004年至今16年+的時間里，按理DDD這套東西早就應該過時了，尤其在是IT圈中，十多年間IT技術變化飛快，很多人連Java8還整不明白，人家已經推出了Java17，但當我們翻看網路上面DDD相關的文章與書籍的時候，發現這套思想與戰術相當活躍，被一些互聯網大廠，保險公司和金融公司廣泛使用，這個時代的技術人員是幸運的，2010年前的DDD學習者所經歷的那段知識蠻荒何其悲哀，
縱觀網路上對DDD的評價，有嘲諷的、有鼓吹的、有茫然的，你能在他們的臉上發現世間百態，不過總結起來，大家一致的想法是：“真難”，其實也很正常，Evic Evans、Martin Fowler這幫人可是這個圈子的絕世高手，常年混跡在國外各類面向物件圈子，當您還覺得練武的最高境界是手中無劍心中有劍的時候，那幫祖師爺已經還始自創神功了，況且，早在DDD之前已經有一幫先驅設計出了各類分析與設計方法，與其說老艾創造了DDD，不如說其是對前人及個人經驗的總結與梳理，此外，DDD、微服務這些理論的最初都是英文所寫，圈外老外看著都蛋疼，何況非英文母語國家的人 ？
DDD中的戰略部分中，一開始就講到了子域與限界背景關系，給了讀者一計重擊，我說DDD是超前的，為什么呢？讓我們的腳步回退到2010年之前，那是個沒有k8s、Docker、Spring Cloud的時代，假如我們嚴格按書的理論，把一個大型的系統分離成了很多很多的小系統，比如100個，即便有個一流高手，對系統做了合理的拆分，誰敢去高落地？100個服務，即使是雙實體服務數量也高達200，怎么部署？服務間的呼叫鏈路如何跟蹤？服務如何管理？所以說，“看不懂，不理解”很正常，那東西本來也只能有選擇的落地，2010年后各類云原生技術有了高速發展，此時才是DDD大展伸手的最好時機，
再來談一下微服務與DDD的關系，微服務是一套思想也是一種架構風格，Martin Fowler大概于2004年提出，現在其所以可以大行其道，是因為有一套完整的云原生技術做支撐，部署有容器，流程有DevOps和各類工具，開發技術有Spring Cloud，可是一套系統想要使用微服務架構，最起碼得先把微服務拆出來，這個就是DDD要干得事情了，它有一套理論告訴你如何將系統劃小，還有一套技術告訴你如何針對每一個劃小后的系統進行設計，所以，兩者之間是一對兒老鐵，著重提一句，如果您的公司組織結構不適合微服務架構（比如部門10個人，8個當領導的；比如開發同時也是運維），整個單體或有限個小單體沒毛病，DDD不一定要使用微服務架構，一流高手即使最初是以單體方式落地一個系統，也可以在后續實作系統的快速拆分，這叫“專業”，
學習DDD之前，推薦幾本老書看看，書多且厚，您怎么也得每天認真的看1個小時吧？花花世界傭訓忒大，努力讓自己做沉浸式閱讀，
- Head First 設計模式：學習一些基礎的面向物件概念和重要的設計模式，為實際落地作準備
- UML和模式應用：學習如何建模
- 企業應用架構模式：拓寬一下眼界
- 實作領導驅動設計：很厚重的一本，相對老艾的更加務實，推薦重復閱讀
- 領域驅動設計：軟體核心復雜性應對之道，DDD開山之作，挺玄幻的
開場講完，DDD對人的要求賊高，怎樣才能在DDD的路上走得更遠，且聽下回分解，最后，一句“天行健，君子以自強不息”與讀者共勉，
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/423676.html
標籤：其他
上一篇：戲說領域驅動設計（二）——修身
下一篇：戲說領域驅動設計（二）——修身