1.前言
以我本人目前所见所感，来谈谈应用分层结构的作用。从项目构建的角度来看，它的目录结构取决于选用的构建工具，如maven、gradle等都有约定的目录结构。这一点没有多大变化。但是对于项目的包名管理，应用分层结构我觉得还是很能体现的。从项目群的结构来看也是很能体现应用分层结构的，尤其是在当前流行微服务的时代里。
我们的代码随着项目的应用及需求的变化，会变得越来越复杂和庞大，涉及到的技术也会越来越复杂及多样。如果没有对应用进行分层结构的设置，那么不管是继续开发，还是维护都将显得越来越困难。我们完全可以在一个包里，甚至一个类里，完成所有的事情，如数据处理，业务处理，持久化处理、开放接口等等，所有东西都放在一个地方，风险也高了，如同将所有鸡蛋都放在一个篮子里，一摔就全没了。
所以应用分层结构不仅使我们的项目每个部分的目标明确，还使得项目易于维护和理解。那么应用分层结构本质就是对代码的组织管理，如同一个组织架构。如果分层粒度太大，则起不到有效管理的目的，还容易造成混乱。如果分层粒度太小，则也达不到组织起来管理的目的。因此一个合理的分层粒度对应用分层管理很重要。
2.三层结构
这是三层结构。表现层、业务逻辑层、持久化层，正好是数据依次流过的层。每一层里还包含很多功能各异、目标各异的层次，但总的来说都是为本层服务的。那么这一些就是我们可以考虑的粒度。如下面这个：
- 终端显示层：各个端的模板渲染并执行显示的层，如 velocity 渲染，JS 渲染，JSP 渲染，移动端展示等。
- 开放接口层：直接封装 Service 方法暴露成 RPC 接口；通过 Web 封装成 http 接口；进行网关安全控制、流量控制等。
- Web 层：主要是对访问控制进行转发，完成各类基本参数校验，或者不复用的业务简单处理等。
- Service 层：业务服务层，对具体的业务进行处理。
- Manager 层：通用业务处理层，特征： 1） 对第三方平台封装的层，预处理返回结果及转化异常信息； 2） 对 Service 层通用能力的下沉，如缓存方案、中间件通用处理； 3） 与 DAO 层交互，对多个 DAO 的组合复用。
- DAO 层：数据访问层，与底层 MySQL、Oracle、Hbase 等进行数据交互。
- 外部接口或第三方平台：包括其它部门 RPC 开放接口，基础平台，其它公司的 HTTP 接口。
这种架构的系统，相对来说就比较复杂。这其实是对三层模式的一个细化和优化。细化是为了降低管理的粒度，优化是出于性能的考虑。这样一种架构需要体现到项目的组成上，和项目的代码管理上，才有意义。否则单说项目是属于这种架构的说法是不存在的。
架构更多是在约定的基础上建立起来。只有大家遵守这种约定，项目才能健康发展。因为你完全可以在任意一层里添加相关的不相关的代码去实现你要的东西，但这一定会造成项目代码的混乱。因此对架构的遵守也应该纳入到项目审计中来。
尽管架构很优秀，但应该视我们的系统需要来选择。比较如有很多大公司如阿里巴巴、美团、头条等，通过在各自领域的实践都总结出来适合自己平台的架构。所以在一开始时，可以选用一些成熟的架构来搭建自己的平台。多考虑架构的扩展能力。
我们可以采用微服务的架构风格来实现我们一些大而复杂的架构。如果项目比较小可以用三层架构，典型的就是用MVC框架。其实架构都可以按照实际情况进行裁剪，但是最后都应该较好地映射到实现上。