為什么叫“戲說”呢？領域驅動設計出來的時候就有一種對於受眾的調戲。書是讀完了，您個人升華到了“看山非山，看水非水”的境界。再看一下落地代碼，搞不好會仰天長嘯：“這是我寫的？”。佛家講“空”，儒家講“仁”，領域驅動講“真”。真者，本質也。當您到了“真”的境界，就不會再與別人爭論“到底是java還是C#好”，也不會再糾結“我這個設計合不合理啊？”。很多東西自然而然的就出來了。
回顧歷史，領域驅動設計（Domain-Driven Design，簡稱DDD）大概源起於2004年。有個洋人叫Eric 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的路上走得更遠，且聽下回分解。最后，一句“天行健，君子以自強不息”與讀者共勉。