說到分解，很多人心中的意象大概只有正交分解。正交分解無疑是最重要的一種分析方法，它也是所謂“分而治之”思想最常見的實現策略。但是正交分解一般潛在的假定是分解後的子部分是大致均衡的，它們是相對具有獨立價值的，可以彼此脫離獨立發展。這是分解後實現系統解耦的重要原因。http://canonical.iteye.com/blog/33885 但是物理學中另一種重要的分析學思想是微擾論(Perturbation). 針對一個複雜的物理現象，首先建立一個全局的規範的模型，然後考慮各種微擾條件對原有模型的影響。在小擾動情況下，模型的變化部分往往可以被線性化，被局域化，因而問題得到簡化。微擾分析得到的解依賴於全局模型的解而存在，因而這是一種主從關係的分解方式。但是如果主體模型是我們已經熟知的物理現象，則我們關注的重點可以全部放在擾動解上，認爲所有特定的物理規律都體現在擾動解中。如果微擾分析得到的物理元素足夠豐富，則微擾模型本身可以成爲獨立的研究對象，在其中我們同樣可以發現某種普適的結構規律。
Witrix平臺中系統化的應用主從分解模式，通過類似AOP的技術實現了業務模型與平臺技術的自然結合。http://canonical.iteye.com/blog/126467
最近我們的一個產品的新版本即將在全國範圍內部署，如何有效的控制衆多相近的二次開發版本，同時確保主版本的快速升級，是在架構層面必須解決的問題。http://canonical.iteye.com/blog/73265
在Witrix平臺中，各部署版本並不是直接修改主版本源代碼得到，而是將差異化代碼放在單獨的目錄中進行管理，由系統運行平臺負責將差異化定製代碼與主版本代碼進行動態融合，實現部署版本的客戶化。在這一過程中，系統模型本身支持逆元結構至關重要，否則某些多餘的元素無法通過差異性描述去除，則將出現局部模型失效的情況。
Witrix平臺定義了特殊的_custom目錄，它的內部目錄結構與defaultroot目錄相同，系統平臺優先使用該目錄下文件所提供的功能實現。同時定義了系統參數global.app_id和global.default_app_id，它們分別用來區分當前程序版本以及程序主版本代碼。例如當global.app_id=beijing,global.default_app_id=main的時候，系統中裝載ui.xml這個標籤庫時經歷如下過程，
1. 裝載平臺內置的標籤庫，文件路徑爲 /_tpl/ui.xml.
2. 根據global.default_app_id設置，裝載/_custom/main/_tpl/ui.xml, 其中定義的標籤實現將覆蓋平臺缺省提供的標籤實現。對於那些不需要特殊定製的標籤，繼續使用平臺提供的缺省實現。
3. 根據global.app_id設置，裝載/_custom/beijing/_tpl/ui.xml, 其中定義的標籤實現將覆蓋產品主版本的標籤實現。
基礎平臺中對於代碼動態融合定義了精細的融合策略，將通過編譯技術檢查擴展標籤的接口與缺省實現的接口相兼容，由此確保代碼擴展後不會破壞主版本中的已有調用代碼。
在基礎平臺的實現中，很多實現代碼都是類似
<df:WhenAllowFinishWf>
<df:FinishWfButton />
</df:WhenAllowFinishWf>
這樣的類似廢話的標籤調用。但是通過這些標籤的標記，我們確立了系統的邏輯結構，標定了系統中可以被安全替換的邏輯片斷。