看過微雨心晴（X-Brave）的對架構、框架、基礎件三者關系的論述后，我陷入了一陣不安和恐慌之中。
       發現我原來對軟件框架的理解還是那樣的淺溥，并由此想起，應該不只我一個是這樣，我想大多數的開發人員在從普通的程序員向架構設計轉型時都會遇到的這樣的問題，在闡述的這個問題之前有必要將這三都的關系描述一下(這里就直接引用微雨心晴（X-Brave）的描述)：
        從層次結構來看，軟件架構是從整體上來看軟件設計開發的，框架通常是從較高的層次來實現或者被選擇來實現軟件的架構，基礎件/類是更小的軟件元素，只是更加的強調通用。 三者之間存在微妙的關系，以至于確實容易引起人們的混淆。實際上，試圖完全的割裂它們即使不是錯誤的做法，也常常不是良好的設計：三者之間存在緊密的依賴關系.

我很贊同這種說法，現在我來描述我以前設計系統框架時的問題所在：
最初在第一次擔任框架設計時，總是從功能類出發。
 即：先考慮系統有哪些復雜而又頻繁使用的類，對這此類進行分包，歸類，并命名為UTILS。

然后再是對系統分層，分包，幾乎沒有多少中間接口，相臨層之間總是緊耦合的調用，造成了層與層的改動牽連邊過大。
 
寫出來的框架就像工具包一樣，由一大堆看起來沒有聯系的類堆積而成。

后來，經歷過一次大項目后，開始關注一些建模理論以及開源框架，對先前的框架設計思想產生極大的沖擊，開始關注系統的整體搭配，接口解耦，代碼重用，自動化控制程度有所提高。
但感覺問題還是依然很嚴峻，主要表現在：對系統的把握層次仍然偏低(從代碼角度出發)，缺乏對系統整體的抽象能力和建模能力。對零散的業務規則難以抽象出很好的業務模型并以與系統架構結合起來。

總的來說我經歷了兩個階段：1。以公用基礎件為核心的積木式開發 2。以局部框架結構(實現)為起點，分層整合的泛射式開發(最明顯的問題就是層層之間不成一體，項目越大越到后期就越松散變得越來越難以控制)

目前，開始將目光從系統業務層面出發，以架構為主，逐步向框架結構設計過渡的方向發展，但這時常令我感到力不從心，畢境理論歸理論，現實中還需要豐富的實踐經驗去累積。