在大學里的某一天，一個漆黑的夜晚，我來到了一個學校里陰森的圖書館，雖然說不喜歡，但是為了考試不要零蛋，所以拼死也要溫書了。來到圖書館的柜臺前，遇到了圖書管理員。然后我跟管理員說：“我來借書了”，管理員頭也不抬的把手一指：“書架在那邊，自己去找”。

--------------------------------------------------------------------------------

---------------------------------------------------------------------------------

書架實在是很多，都是分門別類的把書放好在上面的，每個書架上都有標簽，標明了這個書架上放的什么類型的書。

---------------------------------------------------------------------------------

---------------------------------------------------------------------------------

于是我一排排的在書架上開始瀏覽有些啥書

---------------------------------------------------------------------------------

---------------------------------------------------------------------------------

看到一本還不錯的書，我就把書取出來，然后看看書的內容

------------------------------------------------------------------------------------------------

?????

------------------------------------------------------------------------------------------------

看了看，寫的不錯，于是拿著這本書去找管理員：“我要借這本啊”。管理員二話沒說，拿個本子記下來我借了這本書，然后在書上打個標簽

------------------------------------------------------------------------------------------------

------------------------------------------------------------------------------------------------

然后我就接到了這本有用地書，然后回去溫書考試去了。

?

-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

以上的內容只是一個簡單例子的模擬，而生成的類圖也是很粗略的，我們通過對業務行為的分析（經典的借書過程來分析得到上面的圖形-為了簡單我直接用了VS的類圖，其實不是很規范，有很多建模工具可以使用， 領域模型的分析沒有一定之規所以可能每個人分析出來的模型并不相同 ，所以如果你覺得有其他的理由，畫成了其他的樣子，那是完全合理的），回到主題，我們要通過領域模型來驅動我們的設計，但是，我們要弄明白的是什么是領域模型的分析，適合什么地方，什么時候不適合。

領域模型（Domain Model）是一個商業建模范疇的概念，他和軟件開發并無一絲一毫的關系，即使一個企業他不開發軟件，他也具備他的業務模型，所有的同行業的企業他們的業務模型必定有非常大的共性和內在的規律性，由這個行業內的各個企業的業務模型再向上抽象出來整個行業的業務模型，這個東西即“領域模型”。一個掌握了行業領域模型的軟件公司，根本不需要再給人家開發項目了，根本不需要靠軟件開發養活自己了，你光給這個行業的企業提供業務咨詢已經賺得非常豐厚的利潤了。

由此我們可知，領域模型的分析并不是我們要做這個軟件的時候要做的，而是在這個軟件所要實現的業務模式出現的時候就可以開始，所以領域建模比較適合需求比較固定，且業務模式比較成熟的領域。我們首先建立起一個領域模型，然后用最簡單直接的類去實現這個模型。這個時候我們不涉及數據庫以及持久化等等細節，然后對模型進行精化，利用設計模式將類進行分解，將領域模型的類的職責用多個小類來實現。

比如User類，我們可以用Factory模式加上Facade模式把這個類的職能和持久化行為（數據層的行為）解耦。

其實DDD不一定就是代表著臃腫的實體類，而我們很多時候是在自己設計的時候因為對OO和設計模式的運用不夠熟練從而設計出了臃腫的實體類（我自己其實也經常弄出這種類出來-不過通過運用設計模式重構，在大多數情況下是可以改變的）。作為一個合格的程序員，能夠快速的完成需求是必要的條件。但是如果只是要求能夠做出來實現需求，是不是對自己的要求過低了點，我們不光是需要能跑起來的程序，還需要穩定健壯的程序，更甚的是優美的實現程序，如果僅僅是滿足于實現需求，借用星爺的一句話：人沒有追求，那和咸魚有什么分別：）

圖書館驚魂記之一（一個簡單的領域模型的建立過程）