原网址将会不断更新 ： 作程的技术博客 《企业应用架构之分层
- 总结》 it.zuocheng.net
常见分层架构模式
三层架构 3-tier architecture
微软.net 体系推荐的分层结构，因此早期在ASP编码的系统中被广泛应用，同时也被其他语言广泛借鉴。
表现层, Presentation layer(PL)
主要负责数据的输入接口和输出。输入指在WEB、客户端或为外界提供的API的数据请求接口；输出则是Web界面、客户端输出、API的数据输出。
页面模版、 对外API数据格式化、Request接受 、Output推送、 Commander操作都在这一层。
业务逻辑层, Bisiness Logic Layer(BLL)
主要负责从原始数据到结果数据的中间过程。系统中最关键、中重要的一层。也被称作领域层（Domain Layer），领域中所有对象的逻辑关系和功能实现算法都在这一层中。
业务逻辑、服务等处于这一层。
数据访问层, Data Access Layer(DAL)
主要是对原始数据的操作层（CRUD操作），为业务逻辑层或表示层提供数据服务。数据源包括，数据库、文件、网络存储系统、其他系统开放的API、程序运行上下文环境等等。
许多框架中的ORM 、 Active Record 、 Dao 类或库都处于这一层。
三层架构总结
三层架构能较好的满足大部分的业务场景，实现高内聚、低耦合。不同层次之间逻辑解耦或者隔离，变为弱依赖，每层的逻辑内聚。从层次角度看，使系统有了较好的可扩展性。
三层架构的不足有：
- 业务逻辑复杂度高的系统，业务逻辑层将变得庞大臃肿，为了解决这个问题，四层架构/多层架构被人提出。
- 不关注表现层的实现。
四层架构 4-tier architecture
四层架构和三层架构极为类似，分为表示层、服务层、业务逻辑层、数据访问层。除了服务层，其他三层和三层架构的三层几乎一致，而服务层，是对三层架构中业务逻辑层的再细分，以解决业务逻辑层经常出现的臃肿的问题。
四层架构是Java EE（J2ee） 推荐的分层架构，尤其是Java Spring+Struct+Hibernate（SSH）组合的框架 将Dao层、 Service层，做了明确的定义和规范。由于SSH框架被广泛使用，其他框架，包括其他语言的框架（比如PHP）也都借鉴SSH，因此在这些框架里能看到Dao类、Service类的抽象定义。
服务层， Service Layer
在三层架构中，把业务逻辑层的上层逻辑分离出来，组成服务层。服务层往往是逻辑的表示层，即向上层（表示层）提供逻辑的外观。事务控制、安全检查、事务脚本等可以置入业务层（参考Martin fowler 的《企业应用的架构模式》）
四层架构总结
四层架构是三层架构的发展或进化。服务层的出现让三层架构的业务逻辑层不再变得臃肿。
四层架构和三层架构都存在一个不足，就是不强调前端的实现。当面对需要个性化定制界面、复杂用户交互、页面之间有依赖关系时，需要更好的解决方案。
MVC 模式
MVC 模式最主要包括三部分，Model View Controller（模型-视图-控制器）。
相比于三层架构或者四层架构，MVC最突出的优点是前端控制的灵活性。如果MVC的两部分，View和Controller剥离出来，实际上是一种叫前端控制器模式的设计模式。
MVC 的缺点很明显，将前端以外逻辑都放到 Model里，随着业务增多，Model将越来越难以维护。
MVC 并不适合称作一种分层架构，更适合称为一种复合的设计模式。有人还将MVC模式归类为前端架构。
为什么MVC模式被广泛的采用? 笔者是这样认为的：
- MVC模式最适合新闻门户网站、展示类网站，此类网站业务逻辑往往较为简单。
- MVC模式最适合产品初创时被使用，因为项目初期逻辑简单, 使用MVC模式产品能快速成型，可以尽早投放市场进行试验（多数可能会被淘汰），这样就降低了试验成本。（如果产品有潜力，中后期随着业务增多和变得复杂，系统必然面临重构压力。）
- MVC模式最适合产品原型的实现（注重前端）。
其他分层架构
除了三/四层架构，MVC模式，还有很多架构模式，但这些多是与三/四层架构、MVC模式类似，或是在他们之上进行扩展和改造。比如 MVVM （Model-View-ViewModel）、MVP、DDD架构模式等。
关于分层的总结
分层的思想或目的
- 高内聚
- 低耦合
- 增强系统的可扩展性
- 增强系统的可维护性
分层的优点
- 开发人员可以只关注整个结构中的其中某一层；
- 可以很容易的用新的实现来替换原有层次的实现；
- 可以降低层与层之间的依赖；
- 有利于标准化；
- 利于各层逻辑的复用。
- 结构更加的明确
- 在后期维护的时候，极大地降低了维护成本和维护时间
分层的缺点
相比于分层的优点，分层的缺点显得微不足道。
- 使用分层虽然增多了代码量，但清晰的架构和代码复用却降低了开发成本、维护成本。
- 分层虽然在逻辑上增多了代码的调用、增多了逻辑分支，降低了性能，但是这部分降低的性能与系统中真正的性能瓶颈（存储IO、网络IO、高层次的语言）相比，显得实在渺小。
- 分层有时会导致级联的修改，但这种情况是可以通过面向接口的设计或者使用中介者模式、门面模式、适配器模式等设计模式解决。
如何设计分层架构
- 软件的发展都是遵循着从简单到复杂的过程，软件架构也是一个迭代的过程，是一个循序渐进，不断完善的过程。简而言之，不断地重构。
- 借鉴或者直接使用Java EE（j2me）的分层规范，并使用dao、service等类的命名。
- 层与层之间交互部分，要遵循面向接口设计的原则，不吝舍使用设计模式。
- 分层的选择要平衡成本和风险，使收益最大化。
- 业务逻辑不要局限于四层架构或三层架构，依据领域业务特点可更细地划分层次。