canonical

    說到分解，很多人心中的意象大概只有正交分解。正交分解無疑是最重要的一種分析方法，它也是所謂“分而治之”思想最常見的實現策略。但是正交分解一般潛在的假定是分解后的子部分是大致均衡的，它們是相對具有獨立價值的，可以彼此脫離獨立發展。這是分解后實現系統解耦的重要原因。http://canonical.javaeye.com/blog/33885 但是物理學中另一種重要的分析學思想是微擾論(Perturbation). 針對一個復雜的物理現象，首先建立一個全局的規范的模型，然后考慮各種微擾條件對原有模型的影響。在小擾動情況下，模型的變化部分往往可以被線性化，被局域化，因而問題得到簡化。微擾分析得到的解依賴于全局模型的解而存在，因而這是一種主從關系的分解方式。但是如果主體模型是我們已經熟知的物理現象，則我們關注的重點可以全部放在擾動解上，認為所有特定的物理規律都體現在擾動解中。如果微擾分析得到的物理元素足夠豐富，則微擾模型本身可以成為獨立的研究對象，在其中我們同樣可以發現某種普適的結構規律。
    Witrix平臺中系統化的應用主從分解模式，通過類似AOP的技術實現了業務模型與平臺技術的自然結合。http://canonical.javaeye.com/blog/126467 最近我們的一個產品的新版本即將在全國范圍內部署，如何有效的控制眾多相近的二次開發版本，同時確保主版本的快速升級，是在架構層面必須解決的問題。http://canonical.javaeye.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, 其中定義的標簽實現將覆蓋產品主版本的標簽實現。

基礎平臺中對于代碼動態融合定義了精細的融合策略，將通過編譯技術檢查擴展標簽的接口與缺省實現的接口相兼容，由此確保代碼擴展后不會破壞主版本中的已有調用代碼。
    在基礎平臺的實現中，很多實現代碼都是類似

這樣的類似廢話的標簽調用。但是通過這些標簽的標記，我們確立了系統的邏輯結構，標定了系統中可以被安全替換的邏輯片斷。