隨着微服務架構的不斷流行，很多企業開始在自己的業務中落地微服務。他們覺得采用微服務架構會讓系統的開發與運維管理變得簡單高效，並且還能提高系統的可用性。
但是當他們實際執行的時候，才發現就算採用了微服務架構也不能解決他們的問題，反而帶來很多開發與運維上的負擔。
於是他們就試着去找解決方案，最後很多人發現其實是自己劃分微服務的方法錯了，他們應該用 DDD（領域驅動設計） 的思想去指導微服務的實踐。
那什麼是DDD呢？DDD與微服務之間到底有着什麼樣的聯繫？DDD 資深專家、Event Storming 之父 Alberto Brandolini給出了自己的答案。
用一句話來說，DDD 是一種在面向高度複雜的軟件系統時，關於如何去建模的方法論，它的關鍵點是根據系統的複雜程度建立合適的模型。
具體來講，DDD 方法論在系統建模過程中，可以爲團隊中的各個角色提供一套“統一語言”，避免組件劃分過程中的邊界錯位，完成領域圖預演、需求分析、架構模型、代碼模型、測試等工作。“統一語言”的概念在 DDD 中極爲重要，因爲在一個系統的構建過程中，往往業務人員關注的是業務架構，而技術人員則關注系統架構的表述方式。這就導致在將業務架構映射到系統架構的時候，需要經過一層“翻譯”工作，這就會使工作變得複雜、低效。在 DDD 中，只要使用一個“統一語言”，就可以直接將業務架構與系統架構綁定，不需要進一步去翻譯，從而增強系統對業務的響應速度。
另外，DDD的中文翻譯“領域驅動設計”中的“領域”一詞指的是要實現的軟件系統所要解決的實際問題所處的整個領域範圍，它不僅包括系統架構的相關問題，還涉及到系統所支持的業務等內容，但它是與具體的開發技術無關的。也就是說 DDD 關注的是要構建的系統中，關於所要解決的問題的業務、流程和數據等內容是如何工作的，在這些東西理清之後，DDD 去構建出一個模型，接着再去選擇具體的實現技術。DDD 強調的是解耦具體實現技術，所以它可以迅速梳理核心業務邏輯。
總結起來，DDD 的一個生命週期是這樣的：在設計和實現一個系統的時候，這個系統所要處理問題的領域專家和開發人員以一套統一語言進行協作，共同完成該領域模型的構建，在這個過程中，業務架構和系統架構等問題都得到了解決，之後將領域模型中關於系統架構的主體映射爲實現代碼，完成系統的實現落地。而用什麼方式去做領域模型的構建，方法是多樣的，Alberto 自己就爲此發明了 Event Storming（事件風暴），併成爲了一種經典的 DDD 落地模式。
理解了DDD的核心理念，你就不難理解它和微服務的關係了。DDD的本質是一種軟件設計方法，而微服務架構是具體的實現方式。微服務架構雖好，但是他並沒有給出如何對複雜系統進行分解的具體方法論，而DDD正好就是解決方案。
如上就是Alberto對於DDD的全部解釋，希望對你有所幫助。另外，極客時間App正在籌備DDD相關的專欄，如果你對這個專欄感興趣，歡迎掃描以下二維碼進羣給我們反饋。
