領域驅動設計（DDD）在互聯網興起之前很流行，但是互聯網的興起一段時間不再強調領域驅動設計。在互聯網處理，業務比較單薄，基本上都是CRUD就能搞定，同時，互聯網業務要求快速上線，儘快搶佔市場。這些特點導致領域驅動設計的有點沒有辦法充分的發揮。隨著互聯網業務的成熟和複雜話，開發人員發現添加新功能變得十分困難，再去回顧軟件架構，發現已經變成了“大泥球”。這時領域驅動設計的價值就能夠得以體現了。所以現在領域驅動設計開始再次流行起來。
領域驅動設計的目的就是找到行業內通用的模型，非常適合開發行業軟件。領域驅動設計是由內而外的，很像修煉“內功”，從領域模型出發，在限界上下文中利用實體、值對象、領域服務等對業務邏輯進行建模。而用例驅動設計則更像是修煉“外功”，從業務用例推導系統用例，通過系統設計、概念設計、開發設計等得到最終的類。如果業務需求變更或者有新需求，領域模型的變化是內聚的、可控的，相對容易很多。
領域驅動設計用一句話來概括就是“在一個限界上下文中使用通用語言去表達業務”。為了能夠將業務沒有差別的反映到開發模型上，需要使用通用語言將領域專家、架構師和開發人員串聯起來。這樣可以保證需求可以不失真的反映到代碼上。在領域驅動設計中，領域專家是必須的。他們一般在軟件所要解決問題的行業浸淫多年，非常熟悉當前的業務邏輯。有了他們，我們才能夠非常準確的定義出領域模型。不然是無從談起領域驅動設計的。
在一般的開發過程中，我們的模型充斥著大量的“貧血模型”。什麼是貧血模型呢？貧血模型是隻有get和set方法，而沒有業務邏輯的模型。在JAVA圈中，很多框架通過反射的方式初始化對象，所以要求必須有相應的get和set方法。從而導致很多人會認為模型就是帶有一堆get和set方法而沒有業務邏輯的對象。曾經有同事針對“MVC”提了個問題，MVC中的M是指“模型”，可以模型只是帶有數據的對象的而已，怎麼會把這種對象跟V和C相提並論，感覺不到模型存在的意義。其實是貧血模型使他對模型產生的誤解，認為貧血模型就是所謂的“模型”。貧血模型有什麼缺點呢？由於貧血模型不帶有業務邏輯，導致業務邏輯都分散到使用模型的應用層了，多個模型的業務邏輯在應用層交織在一起，導致了“大泥球”，對以後需求的變更和新需求的添加造成了阻礙。
領域驅動設計的目的就是建立能夠反映業務的模型，模型的業務邏輯內聚，可複用性強。
閱讀更多 java技術小碼農 的文章
