看过微雨心晴（X-Brave）的对架构、框架、基础件三者关系的论述后，我陷入了一阵不安和恐慌之中。
       发现我原来对软件框架的理解还是那样的浅溥，并由此想起，应该不只我一个是这样，我想大多数的开发人员在从普通的程序员向架构设计转型时都会遇到的这样的问题，在阐述的这个问题之前有必要将这三都的关系描述一下(这里就直接引用微雨心晴（X-Brave）的描述)：
        从层次结构来看，软件架构是从整体上来看软件设计开发的，框架通常是从较高的层次来实现或者被选择来实现软件的架构，基础件/类是更小的软件元素，只是更加的强调通用。 三者之间存在微妙的关系，以至于确实容易引起人们的混淆。实际上，试图完全的割裂它们即使不是错误的做法，也常常不是良好的设计：三者之间存在紧密的依赖关系.

我很赞同这种说法，现在我来描述我以前设计系统框架时的问题所在：
最初在第一次担任框架设计时，总是从功能类出发。
 即：先考虑系统有哪些复杂而又频繁使用的类，对这此类进行分包，归类，并命名为UTILS。

然后再是对系统分层，分包，几乎没有多少中间接口，相临层之间总是紧耦合的调用，造成了层与层的改动牵连边过大。
 
写出来的框架就像工具包一样，由一大堆看起来没有联系的类堆积而成。

后来，经历过一次大项目后，开始关注一些建模理论以及开源框架，对先前的框架设计思想产生极大的冲击，开始关注系统的整体搭配，接口解耦，代码重用，自动化控制程度有所提高。
但感觉问题还是依然很严峻，主要表现在：对系统的把握层次仍然偏低(从代码角度出发)，缺乏对系统整体的抽象能力和建模能力。对零散的业务规则难以抽象出很好的业务模型并以与系统架构结合起来。

总的来说我经历了两个阶段：1。以公用基础件为核心的积木式开发 2。以局部框架结构(实现)为起点，分层整合的泛射式开发(最明显的问题就是层层之间不成一体，项目越大越到后期就越松散变得越来越难以控制)

目前，开始将目光从系统业务层面出发，以架构为主，逐步向框架结构设计过渡的方向发展，但这时常令我感到力不从心，毕境理论归理论，现实中还需要丰富的实践经验去累积。