如果说设计模式是从代码角度为系统降低耦合度，那么架构风格便是从数据角度解耦。
架构是更加宏观和全面的视角，它不再是解决单一的技术问题，而是为系统提供更加完整的解决方案。
架构风格是一种粗粒度的软件模式，为常见软件问题提供解决方案，促进软件的重用。
常见的软件架构风格如下:
1.Pipe & Filter
2.Batch
3.VM
4.Layered Architecture
5.MVC, PAC
6.MicroKernel
7.Event System
8.Blackboard System
9.Broker, C/S, P2P, SOA
每种架构风格适用于某种特定的问题域，比如第九项全部是分布式计算领域的架构风格。
从用户最常见的GUI和CUI环境视角看：
CUI常常是具有单一输入和单一输出，比较擅长处理有机械性、重复性和规律性的问题。
GUI更擅长有交互性的任务，它的输入和输出之间时常会变化并加以排列组合。
CUI和GUI是一种演化的关系：
1.当输入是单一流或者多个单一流时，架构风格往往是Pipe & Filter/Batch/N Layered。
2.当输入是多个流时，架构风格通常是MVC/PAC。
3.当需要合并多个输入流时，则会使用Event System/MicrosKernel。
4.当需要合并多个输出流时，则会使用Blackboard System。
对于1，在Linux中系统管理员和程序员常用Pipe & Filter处理文本流；而在流媒体系统中，Pipe & Filter用来demux视频流和音频流。这种固定输入流的任务很容易实现批量功能而
变成Batch状态。VM虚拟机可以简单看作是复杂输入而没有相应输出的任务。Layed Arch是一种存在依赖的Pipe & Filter，它的处理顺序和流程已经事先设定好。
对于2，MVC不仅仅是设计模式，当它能解决多个输入流问题时，它成为为一种架构风格。
MVC以及其衍生的MVVC, MVP, PAC将输入模块，数据模块和协调控制模块分解开来。类似的模型比较强调Control的作用。
对于3和4，它们常常和MVC共同使用。3, 4代表一种处理更复杂问题的一般思路。数据可能是输入或输出，也可能是一种解耦的方式。比如实现接口的虚表就是一种解耦数据。直接传递数据会降低系统性能，上下文情景分析和有效数据分离都会增加计算时间开销。
Event System往往会维护原始的上下文和当前变化数据的信息，这些数据出现在输入流的最开始处理阶段或着是前后处理模块的衔接过程。Blackboard System强调了Model的作用，拥有共同的Model特别是Domain Model可以在更宏观的层面上为系统解耦或接入更多的生产者与消费者。
