對一些需求變化多樣的產品而言，做好可變性設計是非常重要的。國外做得好的有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，可支援描述介面、領域物件/服務、資料庫表以及它們之間的繫結關係，如果物件模型有變更、或者業務邏輯有變更，會導致這三層的物件的變化，而變化可基於這三層的元模型描述，實現配置即可用。
金蝶BOS 彈出介面
map map new uicontext this 這裡可以用map傳引數 map.put uicontext.owner,this string errorviewuiclass com.kingdee.eas.custom.kongzhizhongxinrenwuchuli.client.ch...
金蝶bos值更新事件
值更新事件，在金蝶開發中經常用到，學會值更新事件，載入更新 儲存規則也自然搞明白了。值更新的意思 欄位1改變 欄位2改變 比如 輸入職員，自動帶出其所在部門 或者兩個或多個欄位的某種關係 如何設定呢 值更新有很多態別，這裡我只說兩種常用的，就是第一種和第二種 1 攜帶當前字段相關基礎資料屬性到指定列...
金蝶BOS如何讓ERP隨需應變
金蝶erp所具備的各種先進的技術特性各種各樣解決系統重構 系統整合的工具與平台。這些特性和工具幫助金蝶erp能夠快速實施，快速配置，快速應用，快速見效，有效地縮減金蝶erp的應用實施週期和成本。在金蝶erp的整個企業資訊化藍圖中，企業不同角色的使用者可以分別使用 金蝶bos 所提供的不同的應用及工具...