设计一个架构，面临的首要问题是如何进行分解，分解后的组件相互如何组织在一起。从这个意义上说，架构有很多种，而最典型并且在企业中应用最广泛的非分层架构莫属了。分层架构直观来讲就是一种“分层蛋糕”，每一层都依托在其下层之上，上层使用下层定义的各种服务，而下层对上层一无所知。这方面的例子非常多，例如计算机本身分成硬件抽象层，操作系统层，系统软件和应用软件层，互联网ISO 7层架构等等。这也印证了一句名言--“计算机中的任何问题都可以通过增加一个中间层来解决”。
分层架构具有很多优势：
- 上层无需了解下层的实现细节，每一层都是一个有机整机；例如无需了解以太网如何运行，你依然可以用TCP/IP协议来编写FTP服务。这一点对于广大技术人员尤其是程序员至关重要，否则我们每次编写应用的时候都既要知道硬件、又要了解操作系统，还要懂编译器
- 下层可以实现透明的替换，只要替换前后提供相同的服务接口。例如FTP服务可以运行在PPP上，也可以运行在以太网上
- 层次之间的依赖很小，例如只要TCP/IP协议不变，FTP服务就不变，无论数据链路和物理层发生怎样的变化
- 分层明确了了每层的功能和接口，有利于进行标准化
- 下层可以为上层多个服务提供支持，只要服务遵循相同的调用接口
分层架构同时也有自身的缺陷，主要有以下两点：
- 层次不能封装所有的东西，最典型的代表就是如果要在用户界面显示增加一个数据域，则数据库中需要增加相应的字段，并且业务层也需要做相应的修改。
- 过多的层次会加大调用开销，从而影响性能。
企业应用架构的演变经过了以下几个阶段（主要是指单个应用的架构）:
- 两层架构 - 以客户机/服务器系统为代表，客户端（胖客户端）负责用户界面和业务逻辑，服务器就是关系型数据库。常见的工具有VB，PowerBuider等，一般来说这个阶段业务比较简单，主要就是数据库的增删改查，通过用户界面上的SQL感知控件来连接和操作数据库。
- 三层架构 - 我认为也可以称为四层架构（如果算上数据库），即表现层、领域层和数据源层。表现层用来处理与用户的交互，可以是命令行、胖客户端或者web界面；数据源层主要关注和其它系统的交互，如数据库、消息系统、缓存或其它；领域层主要负责执行领域逻辑，完成相关的计算。
在本系列中，我们主要关注分层架构，至于后来出现的SOA和微服务架构，以及驱动这些架构出现的原因，会在另外的文章中分析。
另外，对于三层架构，我们需要注意以下几点：
- 三层架构的每一层可以在垂直方向上进行再拆分，形成不同的软件包，例如表现层分为命令行和web界面，数据源层分为数据库、文件系统等
- 在实际应用中，下层对于不相邻的上层并不是完全透明的，例如有时为了效率或其它考虑，可能会从表现层直接访问数据源层
- 分层架构指的是逻辑上的分层，而从物理上来看，可以有多种部署架构。例如Java中可以三层都放在同一个JVM（Tomcat）中；也可以把表现层放在Tomcat中，而业务逻辑放在JBoss EJB（另外一个JVM，甚至是不同的服务器）中。