框架、架构和设计模式之区分



【转载】      

1、软件系统是由不同粒度的软件单元层层递归构成的，如子系统、模块、类；由于在实践中所处的位置不同，同一个软件单元在不同实践者眼中的粒度可能不同。

子系统也有架构。即使是同一系统内部，子系统不同，所采用的架构也有可能不同，如报表子系统采用事务脚本架构，而拓扑子系统采用领域模型架构模式；
框架和架构既有区别又有联系，前者是复合组件特例，后者是复合组件的大局设计；
框架也需要架构设计，如Struts作为著名框架自然有其架构；反过来，可以通过架构框架化达到“架构重用”的目的，如很多人都在用Spring框架提供的控制反转和依赖注入来构建自己的架构。

2、框架作为软件系统或子系统的半成品，其设计开发过程从总体上来说和系统开发非常类似（是刻意做成“半成品”的，而不是“还没有做完”），框架也是通过架构设计、详细设计、实现和测试开发出来的。当采用面向对象技术时，框架是一组类和接口，当然还可以包含资源文件和配置文件等等。框架可以很复杂，可以包含成百上千个类，可以划分模块和子系统。

3、架构是问题的抽象解决方案，它关注大局而忽略细节；而框架是通用半成品，还必须根据具体需求进一步定制开发才能变成应用系统。

4、框架是软件，架构不是软件。

5、框架是一种特殊的软件，它并不能提供完整无缺的解决方案，而是为你构建解决方案提供良好的基础。框架是半成品。典型地，框架是系统或子系统的半成品；框架中的服务可以被最终应用系统直接调用，而框架中的扩展点是供应用开发人员定制的“可变化点”。

6、软件架构不是软件，而是关于软件如何设计的重要决策。软件架构决策涉及到如何将软件系统分解成不同的部分、各部分之间的静态结构关系和动态交互关系等。经过完整的开发过程之后，这些架构决策将体现在最终开发出的软件系统中；当然，引入软件框架之后，整个开发过程变成了“分两步走”，而架构决策往往会体现在框架之中。

7、软件架构是比具体代码高一个抽象层次的概念。架构势必被代码所体现和遵循，但任何一段具体的代码都代表不了架构。
8、框架是可以通过某种回调机制进行扩展的软件系统或子系统的半成品。