領域驅動設計（Domain Driven Design，簡稱:DDD）設計思想和方法論早在2005年時候就被提出來，但是一直沒有被重視和推薦使用，直到2015年之後微服務流行之後，再次被人重視和推薦使用。 下麵我來介紹一下DDD設計思想和方法論，同時結合我們在實際項目中應用總結和思考。 目錄 1、為 ...
領域驅動設計（Domain Driven Design，簡稱:DDD）設計思想和方法論早在2005年時候就被提出來，但是一直沒有被重視和推薦使用，直到2015年之後微服務流行之後，再次被人重視和推薦使用。
下麵我來介紹一下DDD設計思想和方法論，同時結合我們在實際項目中應用總結和思考。
目錄
1、為什麼要用DDD
2、DDD架構設計
3、領域建模方法
4、代碼實踐
5、問題總結
1、為什麼要用DDD
面向過程
很多時候，我們都是操著面向對象的語言乾著面向過程的勾當。大部分的系統都是從單一業務開始的。但是隨著支持的業務越來越多，代碼裡面開始出現大量的if-else邏輯，這個時候代碼開始有壞味道，沒聞到的同學就這麼繼續往上堆，聞到的同學會重構一下，但因為系統沒有統一的可擴展架構，重構的技法也各不相同，這種代碼的不一致性也是一種理解上的複雜度。
分層不合理
分層太多和沒有分層都會導致系統複雜度的上升。
隨心所欲
隨心所欲是因為缺少規範和約束。
面向對象
深入的理解面向對象設計原則、模式、方法論有很多，同時要具備非常好的業務理解力和抽象能力。
SOLID是單一職責原則(SRP)，開閉原則(OCP)，里氏替換原則(LSP)，介面隔離原則(ISP)和依賴倒置原則(DIP)的縮寫，原則是要比模式更基礎更重要的指導準則，深入理解面向對象設計原則極大的提升我們的面向對象設計的能力和代碼質量。
分層設計
分層最大的好處就是分離關註點，讓每一層只解決該層關註的問題，從而將複雜的問題簡化，起到分而治之的作用。
領域建模
領域模型可以準確地反映業務語言，使業務語義顯性化，而傳統的J2EE或Spring+Hibernate/Mybatis等事務性編程模型只關心數據，這些數據對象除了簡單setter/getter方法外，沒有任何業務方法，被稱為成貧血模式。
規範設計
各歸其位、命名約定、通用業務狀態碼約定等。
DDD概念定義
領域驅動設計：一種軟體開發方法，是一種軟體核心複雜性應對之道，它可以幫助我們設計高質量的軟體模型。
DDD目的：
- DDD是為瞭解決複雜業務邏輯的問題
- DDD的核心問題不是技術問題，而是關於討論、聆聽、理解、發現業務價值的問題
- DDD是技術人員擁有產品思維的一個體現
- DDD的學習曲線很陡主要是因為它是一種方法論，每個人對它的理解存在差異
領域模型與事務腳本對比
富血模型：就是屬性和方法都封裝在Domain Object里，所有業務都直接操作Domain Object。 service層只是完成一些簡單的事務之類的，甚至可以不用service層。也就是直接從action->entity。
貧血模型：就是一個對象里只有屬性，要實現業務，要依靠service層來實現相關方法，service層的實現是面向過程的，大量傳統的分層應用action->service->dao->entity的方式就是這種貧血的模式實現。
舉個例子，銀行轉賬實現類
各位看官看到上面的代碼是不是有一種似曾相似的感覺？咋一看也沒有啥問題，能正常運行，能快速交付業務。如果僅是為了應付需求任務交差，當然沒有什麼啥問題了。
從設計角度來看確實存在一些問題，代碼糊在一起，沒有分層設計，偽面向對象的方法。
我們碼農總得要有自己一點的追求，為偉大代碼事業創造一點藝術貢獻！
- 如果業務需求快速變化怎麼辦，需求越來越複雜怎麼辦？
- 如果團隊裡面有多人協作，代碼需要經過多人反覆修改接手傳承，你敢保證後面接手的人不會罵你嗎？
- 難道設計上有沒有可以改進的空間？
答案是肯定的！
客觀來說上面的這段代碼不算複雜，也算寫得中規中舉。下麵我來讓貼一段曾經在我們實際生產系統跑了將近一年的神代碼，你才知道什麼叫複雜和神奇！16層if..else+for迴圈！就問你怕了沒有？
》》》請點開看下麵神碼片段
