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