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