分层架构，顾名思义，就是将一个不能解决，复杂的问题进行切分，方便我们对其进行处理。
模式描述：
对于一般的应用，系统都会被分为表现层，业务层，持久层和数据库层.
大致的业务流程如下：
表现层：相当于点单时的小哥，负责与用户交互
业务层：用来实现业务逻辑，也就是炒菜
持久层：负责提供数据，也就是食材
数据库：保存数据
关键概念：层隔离
注意每一层都是封闭的.这意味着Request必须经过每一层才能到达最底下一层. 层隔离的概念意味着你对任何一层的改变都不会影响其它层,这很好理解.层隔离也意味着一个层的组件并不会了解其它层的实现,或者知道很少. 比如业务层不需知道你持久层是由hibernate还是mybatis实现的.
结合上面的例子，也可以知道。你换一个前台小哥是不会影响其他层次的。当然你换一个大妈，得问大爷答应不答应。
架构的考量
- 总体灵活性: 低
- 发布易用性:低
- 可测试性: 高
- 性能:低
- 规模扩展性: 低
- 开发容易度: 高
优缺点
优点
结构简单,容易理解和开发
不同技能的程序员可以分工,负责不同的层,天然适合大多数软件公司的组织架构
每一层都可以独立测试,其他层的接口通过模拟解决
缺点
一旦环境变化,需要代码调整或增加功能时,通常比较麻烦和费时
部署比较麻烦,即使只修改一个小地方,往往需要整个软件重新部署,不容易做持续发布
软件升级时,可能需要整个服务暂停
扩展性差.用户请求大量增加时,必须依次扩展每一层,由于每一层内部是耦合的,扩展会很困难
规则
1．系统各层次及层内部子层次之间都不得跨层调用。
2．Entityobject 在各个层之间传递数据。
3．需要在UI层绑定到列表的数据采用基于关系的DataSet传递，除此之外，应该使用Entityobject传递数据。
4．对于每一个数据库表（Table）都有一个DB Entity class与之对应，针对每一个Entityclass都会有一个BEMClass与之对应。
5．有些跨数据库或跨表的操作（如复杂的联合查询）也需要由相应的BEM Class来提供支持。
6．对于相对简单的系统，可以考虑将Business Function子层和Business Flow 子层合并为一个。
7．UI层和BL层禁止出现任何SQL语句。
小结
分层式设计可以达至如下目的：分散关注、松散耦合、逻辑复用、标准定义。一个好的分层式结构，可以使得开发人员的分工更加明确。一旦定义好各层次之间的接口，负责不同逻辑设计的开发人员就可以分散关注，齐头并进。
参考文章：