最近看了看領域模型驅動這本書，只看了前面幾章，但也深切的感受到了模型的重要性。通過與**同步的模型，能夠維護乙個很好的知識共享的空間，包括設計者與程式設計師之間，客戶與設計者之間 …… 而且模型應該盡可能簡單，讓不同背景的人都能夠很快學會，並都能對模型有所增益。
那麼這個模型應該是什麼樣的？書我沒有細看，只說說自己的體會。關於設計，很早就有資料驅動和物件驅動的提法。在 without ejb 裡， rod 也有講：資料驅動或者說面向資料庫設計更成熟，工具更多；而物件驅動更符合物件導向程式的特性，但由於掌握的人較少，風險較大。而通過模型驅動，我認為很大程度填補了 2 種方式的鴻溝，核心是模型，具體是物件模型還是資料模型並不重要，重要的是這個模型能夠與需求、**、資料庫保持一致。
說到這裡，順便談一談我對文件的理解。我一直是 xp 的堅定支持者，甚至有點偏執。而由於文件不易閱讀和溝通，且經常會出現與設計和**的脫節，導致其可讀性更差，所以我一向對文件不大感冒，更傾向於使用**說話。但在目前的公司專案中，由於更多採用傳統的軟體過程，我也寫了很多的文件，包括需求規格說明書、概要設計文件、詳細設計文件等等。從對專案的幫助來看，文件作用並不太大，或者說是付出收益比太低，更多的是給客戶寫的，而不是給程式設計師寫的。從程式設計師的需要來看，他關心的是每個實體的屬性和關聯，核心的介面、輸入和輸出，頁面間的跳轉和資料流，然後有乙個統一的框架和程式設計模式。我的體會是：如果以文件為核心，很難描述清楚這些東西，且難以應對變化。
而通過以模型為核心（專案現在採用的 power designer 的概念模型為基礎），輔以適當的描述，既能夠加快大家對專案的認識（程式設計師是後面才加入），又能夠節省一些寫文件的時間，更早投入開發。
說到 power designer ，我也比較慚愧。用了好久，一直只是把它當成看資料庫的工具。專案一開始就是從物理模型入手，結果舉步維艱。後面從概念模型入手，就感受到了它的好處。使用概念模型，不用考慮太多關聯表、外來鍵什麼的，而是從實體出發，然後確定相互間的關聯，是一對
一、一對多還是多對多。然後自動轉成物理模型，並直接與相應的資料庫掛鉤。從這點上看與從物件設計出發真的非常相似。其實這也是合情合理的，正體現了這個世界的統一性吧（物理學界不也在搞什麼統一場理論的證明嗎）。 power designer 也做了 conceptual model, physical model, object-oriented model 和 xml model 的自動轉換，我現在還沒全部摸熟。
對「認識」的認識
很早就想談談關於 認識 的認識。這是乙個巨集大深刻的哲學問題。只是覺得沒有完全思考清楚，還以為觀點有些偏頗，擔心自己沒能力系統論述，就遲遲沒有動筆。但想到談論的問題本身就是乙個偏頗的問題，而且，我始終覺得，問題儘管偏頗，但卻不無道理。所以，提筆寫下這篇文字。正像思想的本質是不安一樣，認識的本質是片面...
富領域模型和貧血領域模型
貧血領域模型乙個明顯的特徵是 它僅僅是看上去和領域模型一樣，都是物件，都以領域空間中定 義的名詞命名，這些物件通過實際領域模型中豐富的關係和結構相互關聯。但是觀察模型所持有的 業務邏輯時會發現，貧血模型中除了大量 getter 和 setter，幾乎沒有其他業務邏輯。當然，在使用貧血領域模型時，那些...
建立領域模型
領域模型是對領域內的概念類或現實世界中物件的視覺化表示。又稱概念模型 領域物件模型 分析物件模型。它專注於分析問題領域本身，發掘重要的業務領域概念，並建立業務領域概念之間的關係。1 概念類分類表 就是事先分好類，然後由分析人員在需求資訊中尋找相應類別的候選物件進行確定和歸納，形成概念類。顧客向系統提...