目前，主流IT认为有五种软件架构风格，分别是：
1、数据流风格
2、调用/返回风格
3、独立构件风格
4、虚拟机风格
5、仓库风格
所谓的数据流风格就是指，在这种风格下，软件可以分为一系列处理单元，或者称为构件（Component）。这些处理单元有固定的顺序，但是相互之间非常独立。在纯数据流系统中，多个构件之间除了数据交换以外没有任何其他交互。
其中数据流风格又可以细分为批处理序列和管道/过滤器风格。他们之间的相似点都是把任务分解成一系列固定顺序的处理单元，而且彼此之间只通过数据传递进行交互。但是他们之间所不同的地方在于，批处理序列是传递整体的数据，数据必须是整体的，完整的。这也意味着下一个步骤必须要等到上一步完全结束后才能开始。这导致构件的粒度大，延迟高，实时性差，无并发。而管道过滤器风格则可以以增量的方式处理数据，不需要等到上一步处理全部数据后才开始下一步，构件粒度小，相对而言延迟低，实时性强，并且可以有并发。
在实际的工作中，这种风格的架构我接触不多。因为这种架构的特点，决定它适用的领域不是很广，一般局限在代码编译/图片视频音频等处理以及数据转换等项目中。在我印象中我接触过一个管道/过滤器风格的一个项目，这个项目是EDI的一部分，主要负责企业内各个子系统之间的数据交换。这是一个很明显的管道/过滤器风格的架构，但是由于当时尚不知架构风格这么一回事。
管道过滤器风格架构的优点是构件有良好的隐蔽性和高内聚、低耦合的特点。它的耦合属于数据耦合，是仅次于非直接耦合的第二弱耦合。从内聚角度讲的话应该是最强的功能耦合了吧。
该架构允许设计者将系统的输入输出看成是多个过滤器的简单合成，实际情况的确如此。
支持软件重用，可以想到，只要提供合适的数据，任意两个过滤器都可以被连接起来，实现一个新的功能。
系统可维护性比较强。
允许对吞吐量/死锁进行分析。
支持并行。
该架构的缺点是：
通常导致进程成为批处理结构，虽然管道/过滤器风格可以增量地处理数据，但是，他们是独立的，所以设计者必须将一个过滤器看成从输入到输出的转换。
不适合处理交互的应用。
因为没有数据传输的标准，导致每个过滤器都增加了解析和合成数据的工作，这就导致系统性能下降。系统的很大一部分工作都在处理数据转换。
调用/返回风格是当今软件界占据主导地位的架构风格，从C语言以及之前的时代广为流行的主程序/子程序架构，到如今如日中天的面向对象架构风格。还有更宏观一点的层次结构，你会发现全部都是自己熟悉的架构风格。另外还有RPC风格，从架构上来讲跟主程序/子程序风格颇为接近。
层次系统有很多优点，比如基于抽象程度递增的系统设计，使设计者可以把一个复杂系统按递增的步骤进行分解。
支持功能增强，因为每一层至多和相邻的上下两层交互，一般情况下实际上主要是下层，所以其他层次的改变不会影响。
层次系统的不足是系统不容易划分层次，甚至出于性能考虑，不能将一些功能分层。
不过由于这种架构风格的流行，对于许多领域，已经有了一些公认的分层方法。比如Web系统中，从前端到后端，依次有表现层，功能层（业务逻辑层）。同时，如果采用面向对象的方法进行设计开发的话，那么该架构又有面向对象的风格。
第三种，独立构件的架构风格，在某种程度上和第一种数据流风格有一点点相似。独立构件架构中，构件是独立过程，这与前述第一种有点相似。连接件是消息传递或者事件触发。这和第一种架构不同，第一种架构中连接件是数据。
这种架构的优点是他为软件重用提供了强大的支持，有人将这种架构的系统成为柔性系统，意思是系统某一部分的变动不会影响到其他部分。这包括功能和性能两部分的影响。当然，这种架构也是有缺点的，因为其“柔性”，所以构件放弃了对系统计算的控制。在调用/返回架构下，调用者对被调用者的控制是比较强的，它总是能在确定的时间点得到结果（或者得到错误）。但独立构件风格下，一个构件触发一个事件时，不能确定其他构件是否会响应它，在什么时间内响应它。另外一个问题是数据传递的问题，在某些情况下，数据不能随着时间传递（在数据比较大的情况下），而是要到共享的仓库内去取，这样全局性能和资源管理便成了问题。
第四种风格，虚拟机风格。这种风格显然一般很少接触到，主要分解释器和基于规则的系统。
第五种，仓库风格。数据库系统是仓库风格的最常见形式。另外还有黑板系统，超文本系统。这个要进一步深入了解。
解释器风格
原文：http://www.cnblogs.com/jhgf/p/5327911.html
