大家好，我是編程樂趣。
今天不推薦開源計畫，我們今天來聊聊為什麽有DDD這個東西。
因為我在星球裏有寫DDD的教程，所以也有很多學員就是沖著這個教程加入星球的。
但其實有很多開發人員，不明白為什麽要學習DDD。
其實對於我們程式設計師來說，不明白為什麽學這個技術、學這個技術能解決什麽問題，是非常致命的。
你不知道為什麽而學習，是非常可怕的，也往往學不好。
很多人說是因為DDD現在流行，所以要學習。雖然不能說這樣的想法錯了，但就因為流行才學習，很多人是會學不明白的，而且學完也不知道如何去運用。
下面我們聊聊三層架構與DDD的區別。
首先是三層架構，這個大家都很熟悉，就是把系統分為：表示層、業務層、數據存取層，為什麽要這樣分層呢？
相信大家都很了解，每一個層職責和功能是不一樣的，表示層是負責前端的展示、業務層負責處理我們核心業務、數據存取層只負責與資料庫打交道不涉及業務，在這裏體現了「高內聚，低耦合」的編程思想。
如果計畫比較小，這樣的分層是沒有問題的。但是假設我們業務一直在發展，表示層與業務層的程式碼肯定是逐漸膨脹的。這就會導致原本清晰的程式碼變得難以維護。
所以，這時候就需要DDD了。
說到DDD，很多人都會被其中的概念搞暈，比如：領域模型、領域邊界、上下文、規約、聚合、值物件等。
其實這麽多概念我們先不要去管它，而是要先理解DDD是解決什麽問題。
原本在三層架構裏，所有業務程式碼都是放在業務層裏的，業務復雜後，就會導致業務程式碼非常龐大、非常混亂、不好管理。而 DDD引入領域的概念，我們把業務劃分為不同領域，這樣子就能使得業務層變得清晰。但領域與領域之間肯定有關聯的、需要相互操作通訊的，為了解決這些問題，才會引入那麽多的概念。
所以，針對三層架構與DDD架構，我個人更願意用一句話來說明他們的區別：
三層架構是根據程式碼的不同職責進行分層解耦；而DDD是在三層架構的基礎上，對業務按領域進一步解耦。
不管是三層架構還是DDD，都逃不過這六個字：「高內聚、低耦合」，只是他們的劃分的程度不同。
我們學習了DDD，可能不會使用到，但至少要了解三層架構的局限在哪裏。
對此你有什麽其他想法，歡迎留言討論！
