canonical

    說到分解，很多人心中的意象大概只有正交分解。正交分解無疑是最重要的一種分析方法，它也是所謂“分而治之”思想最常見的實現(xiàn)策略。但是正交分解一般潛在的假定是分解后的子部分是大致均衡的，它們是相對具有獨立價值的，可以彼此脫離獨立發(fā)展。這是分解后實現(xiàn)系統(tǒng)解耦的重要原因。http://canonical.javaeye.com/blog/33885 但是物理學(xué)中另一種重要的分析學(xué)思想是微擾論(Perturbation). 針對一個復(fù)雜的物理現(xiàn)象，首先建立一個全局的規(guī)范的模型，然后考慮各種微擾條件對原有模型的影響。在小擾動情況下，模型的變化部分往往可以被線性化，被局域化，因而問題得到簡化。微擾分析得到的解依賴于全局模型的解而存在，因而這是一種主從關(guān)系的分解方式。但是如果主體模型是我們已經(jīng)熟知的物理現(xiàn)象，則我們關(guān)注的重點可以全部放在擾動解上，認(rèn)為所有特定的物理規(guī)律都體現(xiàn)在擾動解中。如果微擾分析得到的物理元素足夠豐富，則微擾模型本身可以成為獨立的研究對象，在其中我們同樣可以發(fā)現(xiàn)某種普適的結(jié)構(gòu)規(guī)律。
    Witrix平臺中系統(tǒng)化的應(yīng)用主從分解模式，通過類似AOP的技術(shù)實現(xiàn)了業(yè)務(wù)模型與平臺技術(shù)的自然結(jié)合。http://canonical.javaeye.com/blog/126467 最近我們的一個產(chǎn)品的新版本即將在全國范圍內(nèi)部署，如何有效的控制眾多相近的二次開發(fā)版本，同時確保主版本的快速升級，是在架構(gòu)層面必須解決的問題。http://canonical.javaeye.com/blog/73265 在Witrix平臺中，各部署版本并不是直接修改主版本源代碼得到，而是將差異化代碼放在單獨的目錄中進(jìn)行管理，由系統(tǒng)運行平臺負(fù)責(zé)將差異化定制代碼與主版本代碼進(jìn)行動態(tài)融合，實現(xiàn)部署版本的客戶化。在這一過程中，系統(tǒng)模型本身支持逆元結(jié)構(gòu)至關(guān)重要，否則某些多余的元素?zé)o法通過差異性描述去除，則將出現(xiàn)局部模型失效的情況。
    Witrix平臺定義了特殊的_custom目錄，它的內(nèi)部目錄結(jié)構(gòu)與defaultroot目錄相同，系統(tǒng)平臺優(yōu)先使用該目錄下文件所提供的功能實現(xiàn)。同時定義了系統(tǒng)參數(shù)global.app_id和global.default_app_id，它們分別用來區(qū)分當(dāng)前程序版本以及程序主版本代碼。例如當(dāng)global.app_id=beijing,global.default_app_id=main的時候，系統(tǒng)中裝載ui.xml這個標(biāo)簽庫時經(jīng)歷如下過程，
1.    裝載平臺內(nèi)置的標(biāo)簽庫，文件路徑為 /_tpl/ui.xml.
2.    根據(jù)global.default_app_id設(shè)置，裝載/_custom/main/_tpl/ui.xml, 其中定義的標(biāo)簽實現(xiàn)將覆蓋平臺缺省提供的標(biāo)簽實現(xiàn)。對于那些不需要特殊定制的標(biāo)簽，繼續(xù)使用平臺提供的缺省實現(xiàn)。
3.    根據(jù)global.app_id設(shè)置，裝載/_custom/beijing/_tpl/ui.xml, 其中定義的標(biāo)簽實現(xiàn)將覆蓋產(chǎn)品主版本的標(biāo)簽實現(xiàn)。

基礎(chǔ)平臺中對于代碼動態(tài)融合定義了精細(xì)的融合策略，將通過編譯技術(shù)檢查擴(kuò)展標(biāo)簽的接口與缺省實現(xiàn)的接口相兼容，由此確保代碼擴(kuò)展后不會破壞主版本中的已有調(diào)用代碼。
    在基礎(chǔ)平臺的實現(xiàn)中，很多實現(xiàn)代碼都是類似

這樣的類似廢話的標(biāo)簽調(diào)用。但是通過這些標(biāo)簽的標(biāo)記，我們確立了系統(tǒng)的邏輯結(jié)構(gòu)，標(biāo)定了系統(tǒng)中可以被安全替換的邏輯片斷。