理解起來很抽象。先看個例子!
需求： 我要去釣魚
我沒釣過魚，那我得去百度，
1、買魚竿魚鈎
2、找個適合垂釣的場所
3、選個合適的天氣
4、帶上桶，板凳 等輔助工具
5、理解下釣魚的真諦，浮子動幾下就拉鈎子，河里哪里可能容易掉到就去哪里撒香料
6、本人准備好了就去干！
繼續抽象領域：
1、釣魚工具
2、場所
3、天氣
4、輔助工具
5、技能
6、垂釣者
好了,這6個就是釣魚的主要領域問題。
有了這個領域就可以去知道怎么設計了。
確定業務對象定義、對象間關系、對象名稱和對象間關系名稱的流程使我們能夠以一種能被業務領域專家理解和驗證的精確方式來表達業務領域知識
區別於當前大部分程序員得開發
我們現在都是根據需求不斷的加代碼， 擴展， 迭代， 后期維護非常難， 重構也是很難
領域驅動模型 的設計，能讓開發者更好的去思考系統的開發.
摘抄了一篇文章的解釋：
我們要開發一個系統時，應該盡量先把領域模型想清楚，然后再開始動手編碼，這樣的系統后期才會很好維護。但是，很多項目（尤其是互聯網項目，為了趕工）都是一開始模型沒想清楚，一上來就開始建表寫代碼，代碼寫的非常冗余，完全是過程是的思考方式，最后導致系統非常難以維護。而且更糟糕的是，出來混總是要還的，前期的領域模型設計的不好，不夠抽象，如果你的系統會長期需要維護和適應業務變化，那后面你一定會遇到各種問題維護上的困難，比如數據結構設計不合理，代碼到處冗余，改BUG到處引入新的BUG，新人對這種代碼上手困難，等。而那時如果你再想重構模型，那要付出的代價會比一開始重新開發還要大，因為你還要考慮兼容歷史的數據，數據遷移，如何平滑發布等各種頭疼的問題。所以，就導致我們最后天天加班。