昨天与同事闲聊，同事提了一个问题，既然已经有Spring、Equinox等等这样优秀的框架了，是不是我们在做系统的时候，就可以不考虑系统架构的事了呢。这似乎是个很简单的问题，但是系统的研究一下，我觉得还是对我们理解框架、理解系统架构、设计模式还是有帮助的。

对于象Spring这样的软件开发基础框架来说，框架本身并不解决系统架构的问题，它只是帮助我们更容易的实现一个扩展性更好的系统架构。当然这一点不适应于领域框架，本文并不讨论领域框架的问题，因此下面如无特殊说明，所说的框架都是指的基础框架。前面的文章中已经讨论过，框架为可扩展的组件提供了一个可运行的容器，框架要负责扩展组件生命周期的管理，也要负责协调组件与组件（OSGi中称为服务）之间的依赖、注入关系。但是，框架本身并不负责组件与组件之间在逻辑上是什么样的关系，尤其是在业务逻辑上的关系，框架更是一无所知。因此，即使我们使用了某种框架，每个组件在业务逻辑上的依赖关系仍然是要熟悉业务的系统设计人员所要做的事情。

举一个简单的例子，当某种业务操作发生时，我们要给用户发送一个通知，通知开始只是邮件通知，以后可能会扩展一个短信通知或者利即时消息工具等等，或者也要通知另外一个应用系统，触发它的某种处理。对于这样一个需求，很显然我们可以采用观察者模式来实现。因此，我们可以定义两种类型的组件，一个事件源组件，就是我们自己的系统，这个组件公布了它可以引用多个监听器组件；另一个是要监听系统变化的组件，可能是另外一个系统，也可能负责是发送邮件的组件。然后，可以利用Spring将所有监听器注入到事件源组件中。整个过程，从需求分析、到设计、组件实现、组件装配，Spring帮我们做的仅仅是系统组件的装配而己，而组件与组件之间的依赖关系，仍然是我们在充分理解业务需求的前提下自行设计的。

框架主要的作用就是帮助我们装配组件，但是，往往一个被广为接受的框架，其设计者也会根据自已丰富的项目经验，直接在框架中提供很多应用系统通常都会遇到的架构问题。比如事务、日志、持久化等等。我们可以把这些非业务系统核心功能实现但又被核心功能所依赖的组件统称为辅助业务组件。例如Spring就直接提供了比较丰富的扩展组件，来帮助我们解决这些问题。而OSGi的不同的实现组织也在自己的实现中加入的丰富的各有特色的辅助业务组件的实现。

因此，总结来说，采用框架可以说是实现一个优秀的系统架构设计人员的设计思想的利器，框架可以帮助我们更容易的实现高级设计人员所设计出来的具有高度可扩展性、可维护性、可复用性的系统，并可以帮助我们更容易的实现高级设计人员所设计出来的符合“开-闭原则”、“依赖倒转原则”等等设计思想的系统。