架构模式
---

> 模式就是最好的架构。

####架构的产生

在刚开始接触架构设计的时候，我买了几本书然后就开始学习了。我发现在这些书中都出现了一些相似的东西，如基本的分层设计、Pipe and Filters 模式、MVC 模式。然后，我开始意料到这些模式本身就是最好的架构。

MVC 模式本身也是基于分层而设计的，如下图是 Spring MVC 的请求处理过程：

![Spring MVC](assets/article/chapter8/spring-mvc.png)

而这只是框架本身的架构，这一类也是我们预先设计好的框架。

在框架之上，我们会有自己本身的业务所带来的模式。如下图是我在网上搜罗到的一个简单的发送邮件的架构：

![发送邮件中的 Pipe and Filters 模式](assets/article/chapter8/basic-paf.png)

这样的模式则是在业务发展的过程中演进出来的。

###预设计式架构

日常使用的框架多数是预先设计的构架，因为这些架构本身的目标是明确的。系统会围绕一定的架构去构建，并且在这个过程中架构会帮助我们更好地理解系统。如下图所示的是 Emacs 的架构：

![Emacs 架构](assets/article/chapter8/emacs-architecture.png)

它采用的是交互式应用程序员应用广泛的模型-视图-控制器模式。

无论是瀑布式开发——设计好系统的框架，然后对系统的每个部分进行独立的完善和设计，最后系统再集成到一起。还是敏捷式开发——先做出 MVP，再一步步完善。它们都需要一定的预先式设计，只是传统的开发模式让两者看上去是等同的。

在过去由于 IT 技术变革小，新技术产生的速率也比较低，预先设计系统的架构是一种很不错的选择。然而，技术的发展趋势是越来越快，现有的设计往往在很短的一段时间里就需要推倒重来。

###演进式架构：拥抱变化

演进式架构则是我们日常工作的业务代码库演进出来的。由于业务本身在不断发展，我们不断地演进系统的架构。在这样的模式下产生的架构系统会更加稳定，也更加优美。仅仅依赖于事先的设计，而不考虑架构在后期业务中的变化是一种不可取的设计模式。

这不并意味着不采用预先式设计，而是不一味去依靠原先系统的架构。
