對一些需求變化多樣的產(chǎn)品而言，做好可變性設(shè)計是非常重要的。國外做得好的有Siebel，國內(nèi)有金蝶的BOS，實際上金蝶的BOS很多理念跟Siebel是相似的，呵呵。。。他們都是采用MDD的方式來解決可變性問題的。
這里的難點在于如何抽象出一套穩(wěn)定的元模型，能描述各種各樣的變化，以達到通過配置即可搞定需求變更的目的。
這里著重講一下金蝶BOS的元模型，所謂元模型，是模型的模型。
在數(shù)據(jù)層，有Table，Table對應到數(shù)據(jù)庫表，直接三種Table之間的關(guān)系，什么交叉表、擴展表之類的，基本與平常大家設(shè)計表的范式對應，不多說；
在業(yè)務邏輯層，有實體，實體表示系統(tǒng)的領(lǐng)域?qū)嶓w對象，一個實體對應到一個Table，實體的屬性對應到Table的field或其擴展表的Field，實體與實體之間有關(guān)系，關(guān)系分為One2One，One2Many，Many2One，Many2Many。還可以對實體的屬性定義計算公式，約束。但缺乏實體級別的約束。我認為金蝶可以增加這一個小特性：）。實體可繼承另一個實體，以獲得另一個實體的定義。
可以為實體定義方法，方法映射到一個規(guī)則。也就是說調(diào)用這個方法的時候?qū)嶋H執(zhí)行的是這個規(guī)則；
可以為實體定義查詢方案、過濾方案、排序方案，主要是以O(shè)O的方式做實體查詢，對外暴露OO化的用戶接口，對內(nèi)生成SQL用；
可以為實體定義事件，F(xiàn)unction和Facade可監(jiān)聽事件，事件由Function觸發(fā)。
金蝶對Function的解釋是“業(yè)務功能是對運行系統(tǒng)的Entity對象、UI對象及其方法的一定封裝，供其它模塊或二次開發(fā)使用”，比如上文提到的事件，即是由Function觸發(fā)的，但不知為什么還要指定事件的方法，F(xiàn)unction是事件的生產(chǎn)者，事件的方法表示事件的消費者（監(jiān)聽者），這樣做不是導致生產(chǎn)者與消費者耦合了嗎？？那還要事件干什么，不知道有沒有朋友能解答這個問題？？Function還可以綁定到一個UI的Action，意味著當該UI對象的Action觸發(fā)時，會執(zhí)行這個Function。對UI Action的綁定是可選的。
Facade表示領(lǐng)域Service對象，相比實體，其僅僅有方法，沒有屬性。
UI對象表示一個界面對象，比如訂單創(chuàng)建對象，可以對其指定Layout，UI對象支持綁定實體、Query對象。UI對象也有事件、Action和狀態(tài)，事件和Action應該可以綁定到Function和Facade，State表示界面對象的狀態(tài)，比如界面通常有編輯狀態(tài)、查看狀態(tài)等等。UI對象還有個父對象，還沒怎么弄清楚UI對象與UI對象之間的關(guān)系，沒有看到描述，需要進一步研究；感覺BOS對UI層的抽象略顯簡單，通常UI層是最復雜的，有字段聯(lián)動，子頁面聯(lián)動等等，沒見到BOS怎么來搞定這種聯(lián)動場景。
查詢表示對對象的查詢，需要綁定一個對象樹，可定義查詢方案、過濾方案、排序方案，生成SQL用；
還有其它的一些非主要元模型。
通過UI Object、Entity/Function/Facade、和Table，可支持描述界面、領(lǐng)域?qū)ο?服務、數(shù)據(jù)庫表以及它們之間的綁定關(guān)系，如果對象模型有變更、或者業(yè)務邏輯有變更，會導致這三層的對象的變化，而變化可基于這三層的元模型描述，實現(xiàn)配置即可用。