我的架構學習實戰記錄：資料庫階段

對我而言，認識BLL層的作用，或者領域模型驅動的含義，最大的干擾來自資料庫。

我們很清楚的知道UI層的含義，也知道資料層是做什麼的。但對於一個簡單的（甚至是相當複雜的）系統而言，實在不知道除了對資料庫進行增刪改查以外，還能做些什麼？釋出一篇部落格，不就是在資料庫裡插入一條記錄麼？點選一下推薦，不就是在資料庫裡做一個update麼？

為了避免資料庫的干擾，這裡，我們設定：不使用關聯式資料庫做儲存！請大家牢記，為了更清晰，更深刻的認識到這一點，我們再次明確，我們將使用最流行的NoSQL技術。牛叉吧！興奮吧？

打滿了雞血吧！

好的，設計的任務交給你了，小李同學。

接下來，你怎麼辦？哎呀，我對NoSQL還不熟呀（不熟？其實除了名字知道以外，其他什麼都根本就不知道）。馬上開始研究一下NoSQL，看看裡面有沒有什麼庫呀，表呀之類的，好像那裡面用的是集合？

如果你這樣走下去的話，就偏離了DDD的宗旨了（但也不能說你“錯”了）。

我是這樣做的。

問：這個系統要做什麼？有哪些功能？

答：釋出部落格，部落格可以評論。可以提問題，回答問題。當然，做這些事，都得註冊登入……

好，根據以上資訊，我們可以抽象出這幾個物件。

這是一個良好的開端。再細緻點，部落格和問題，都必須有標題；而部落格的評論和問題的答案，不需要標題；但不管是部落格還是問題，評論還是回答，都會有一個作者，都要釋出時都要記錄下

釋出的時間，甚至釋出者的IP（基於中國人都知道的原因）。部落格和問題，還要記錄下瀏覽量……

到這裡，你是不是嗅到了一種什麼味道？“不管……還是……都……”，共同的東西！那麼想到物件導向的三大特徵，“繼承”就呼之欲出了。所以我們透過抽象，得到了以下的物件。


   

這樣做的好處，很明顯的，就是減少了重複程式碼。“程式碼越少越好”，我深以為然。當然，隨之而來，還有其他好處，容後再表，呵呵。這裡只說一句，良好的抽象是實現設計模式的基礎。

其實，只要有物件導向的思想，進行這樣的抽象是相當容易的（這樣的抽象也是不對的，以後再論述）。但我們常常會被關係型資料庫所干擾（尤其是有一定開發經驗的程式設計師），而不敢進行這種“大膽的”抽象。因為即使將程式碼寫到這裡了，也得面臨一個很現實的問題，接下來怎麼辦？最終我們怎麼把這些物件持久化（儲存到資料庫或其他媒介中去）。這就是我們接下來要進行的工作了。

最後，對那些還想著資料庫的同學，再重複強調一點：這個專案，我們用NoSQL！哦，sorry，改主意了，大家反映NoSQL太難了，又說乾脆用xml檔案吧。