既然是亂彈，當然就不能全用正理推斷，因此文中有文不對題的，思維混亂的都屬正常範疇，大家諒解則個。
架構，是一個神祕也是一個普通的詞彙。
曾幾何時，君不見現在架構師就像雨後春筍似的，忽如一夜春風來，千樹萬樹上面結的都是架構師，不管是招聘的，不管是應聘的，動輒就是資深架構師，高階架構師云云。
有的人說，架構是搞一堆時髦的大家不理解詞彙，最好是一堆一堆的英文縮寫，網上有的，網上沒的，就象華為似的，任你是國內的國外的，沒有縮寫詞詞典管叫你寸步難行，然後再弄一大堆理論出來，然後架構就有了。 有的人說，架構是設計出來的，最好是把SOA，ESB，JCA，設計模式，架構模式， 執行模式，分層模式，多N個Layer，弄M個tier，讓本來清楚點的不清楚，讓不清楚的更不清楚，然後畫一系列的圖，從大到小逐層細化，看懂大的再看中的，看懂中的再看小的，看懂小的，大的已經忘記了。
有的人說，架構是闖出來的，啥子思想，啥子體系，算個屁，偶就厲害，一陣亂拳開啟去，架構自然就出現了。
有的人說，架構是重構出來的，再好的設計，到後面也會變形，如果沒有及時的重構，就會走樣，從正方形，變成長方形，從長方形變成平行四邊形，最後不行了，再重新來過，搞一個新的輪迴。
還有許多許多的牛人，說了N多NB的理論，都有各自己的理解，看看都是正確的，就是學不會，弄不懂，抓不實。
總而言之，言而總之，看了許多，學了許多，還是弄不靈清。今天自不量力來亂彈一下我在做Tiny過程的中架構觀，供大家無事之時揮揮板磚鍛鍊一下身體，疏通一下筋骨。
1. 方法論
方法論這個東東，看了的人都覺得比較虛，其實我也一直覺得比較虛，但是在許多次的實踐之後，才慢慢對這一點有了比較深刻的理解。沒有方法論指導下的架構，實際上就像是沒有長眼睛的蒼蠅一樣，撞到哪裡到哪裡，最後一般來說，做的東西都是缺少體系性的。有的地方可能很強，有的地方可能又比較弱。有的地方有不足，需要進行補充的時候會發現對現有的有嚴重的衝突。甚至在後面，連自己的方向也沒有了，感覺這樣也行，那樣也行，實際上卻是這樣也有問題，那樣也有問題。總而言之方法論對於體系性思維及整體性思考是非常重要的。
2.設計原則
設計原則在於你的框架中最優先考慮的原則有哪些，它有可能是具體的功能需求（一定是重要的全域性影響性的需求，比如：配置需要統一配置，並且要有配置訂閱與釋出機制），也可能是非功能需求，但是對於整個框架都有約束及限制作用（比如：減法原則，讓程式設計師會最少的知識，就可以開展工作；比較DYR原則，永遠不要做重複的事情），同時保證你的路線是在朝既定的路線圖前進。缺少設計原則的架構，在最後，就會表現為特點不清晰，內部矛盾比較嚴重。 3.範圍的確定
作為一個架構或框架來說，包含的內容可大可小，東西可多可少，深度可深可淺，如果沒有範圍的確定，可能在一個問題上就會變成一個深不見底的坑，再也跑不上來。
4.框架的分解
啥東西只要一上升到框架的級別，一般來說就會複雜許多。框架的構建是一個系統工程，一般來說它不是一個人或幾個人可以完全搞得定的。參與的人也各有各的優勢與缺點，因此讓合適的人做合適的事情就是最好的選擇了。因此，要把整個大的系統及框架，分解成小的問題領域，在小的問題領域中，只考慮自己這部分的問題並給出最佳方案。各個小的領域與模組都有好的解決方案並有一個相當不錯的實現方案的話，就為後續的框架奠定了深厚的基礎。當然，每個小的問題領域都要在介面及擴充套件性方面有深入分析、論證，在區域性要力求最優解，當然，一定要遵守前面說的設計元則。
5.框架的整合
框架的整合方面最後採用整合層最薄的原則進行，也就是說，整合成只管進行不同模組之間的黏合，本身不做具體的業務處理。比如：你提供了一個外掛框架，最好外掛框架中只做把普通模組程式碼包裝成外掛的程式碼，但是不要參與業務邏輯的處理。這樣就即保證高內聚與低耦合，又可以進行多模組協作。
那可能有的朋友就要問了，你亂彈了這麼多，你在Tiny框架中是怎麼做的呢？Tiny框架在構建之初就構想了下面的路線圖與設計原則和理念，並在下在趄這個方向前進。
Tiny的路線圖
Tiny的設計原則
Tiny的設計理念