最近看了看領域模型驅動這本書，只看了前面幾章，但也深切的感受到了模型的重要性。通過與代碼同步的模型，能夠維護一個很好的知識共享的空間，包括設計者與程序員之間，客戶與設計者之間
……
而且模型應該盡可能簡單，讓不同背景的人都能夠很快學會，并都能對模型有所增益。
那么這個模型應該是什么樣的？書我沒有細看，只說說自己的體會。關于設計，很早就有數據驅動和對象驅動的提法。在
Without EJB
里，
Rod
也有講：數據驅動或者說面向數據庫設計更成熟，工具更多；而對象驅動更符合面向對象程序的特性，但由于掌握的人較少，風險較大。而通過模型驅動，我認為很大程度填補了
2
種方式的鴻溝，核心是模型，具體是對象模型還是數據模型并不重要，重要的是這個模型能夠與需求、代碼、數據庫保持一致。
說到這里，順便談一談我對文檔的理解。我一直是
XP
的堅定支持者，甚至有點偏執。而由于文檔不易閱讀和溝通，且經常會出現與設計和代碼的脫節，導致其可讀性更差，所以我一向對文檔不大感冒，更傾向于使用代碼說話。但在目前的公司項目中，由于更多采用傳統的軟件過程，我也寫了很多的文檔，包括需求規格說明書、概要設計文檔、詳細設計文檔等等。從對項目的幫助來看，文檔作用并不太大，或者說是付出收益比太低，更多的是給客戶寫的，而不是給程序員寫的。從程序員的需要來看，他關心的是每個實體的屬性和關聯，核心的接口、輸入和輸出，頁面間的跳轉和數據流，然后有一個統一的框架和編程模式。我的體會是：如果以文檔為核心，很難描述清楚這些東西，且難以應對變化。
而通過以模型為核心（項目現在采用的
power designer
的概念模型為基礎），輔以適當的描述，既能夠加快大家對項目的認識（程序員是后面才加入），又能夠節省一些寫文檔的時間，更早投入開發。
說到
power designer
，我也比較慚愧。用了好久，一直只是把它當成看數據庫的工具。項目一開始就是從物理模型入手，結果舉步維艱。后面從概念模型入手，就感受到了它的好處。使用概念模型，不用考慮太多關聯表、外鍵什么的，而是從實體出發，然后確定相互間的關聯，是一對一、一對多還是多對多。然后自動轉成物理模型，并直接與相應的數據庫掛鉤。從這點上看與從對象設計出發真的非常相似。其實這也是合情合理的，正體現了這個世界的統一性吧（物理學界不也在搞什么統一場理論的證明嗎）。
Power designer
也做了
conceptual model, physical model, object-oriented model
和
xml model
的自動轉換，我現在還沒全部摸熟。
openfans
則是從對象入手，并通過
hibernate
建立與數據庫的聯系，也體現了一定的方便靈活性。但比較糟糕的是，只有代碼和配置文件，沒有清晰的便于交流的模型，誰要想參與只能先去慢慢看代碼。所以我先通過
together reverse
出來一個類圖，然后適當加以文字進行說明。類圖已經做好，但比較亂，還需要更多的圖例加以說明。文字說明就是下一篇
blog
的工作了。也算是預告吧！