java 项目--》阿里分层架构设计和实现

为什么要分层：

• 高内聚：分层的设计可以简化系统设计，让不同的层专注做某一模块的事
• 低耦合：层与层之间通过接口或API来交互，依赖方不用知道被依赖方的细节
• 复用：分层之后可以做到很高的复用
• 扩展性：分层架构可以让我们更容易做横向扩展

如何来做系统分层
分层架构的优点还有很多很多，那么我们要如何来做分层设计呢，有哪些关键因素需要考虑？
我个人认为，最重要的一点是要理清楚每个层次的边界是什么。即使是层次分明 Web 项目，当业务逻辑复杂后，也会存在边界越来越模糊的问题，举个简单的例子。
大家开发过的系统中应该都有一个用户服务，最基本的接口就是查询用户信息接口，它的请求链路是，DTO -> Controller -> Service-》DAO 。
这个时候如果PO提出一个需求，当查询的用户不存在时，要自动的创建一个用户，并返回。这个时候逻辑层的边界就开始变得模糊了，因为表现层也承担了一部分的业务逻辑（查询用户和创建用户编排起来）。这个时候我们可以怎么处理? 参照阿里发布的《阿里巴巴 Java 开发手册 v1.4.0（详尽版）》，我们 可以将原先的三层架构细化成下面的样子 :

• 终端显示层：各端模板渲染并执行显示的层。当前主要是 Velocity 渲染，JS 渲染， JSP 渲染，移动端展示等。
• 开放接口层：将 Service 层方法封装成开放接口，同时进行网关安全控制和流量控制等。
• Web 层：主要是对访问控制进行转发，各类基本参数校验，或者不复用的业务简单处理等。
• Service 层：业务逻辑层。
• Manager 层：通用业务处理层。这一层主要有两个作用，其一，你可以将原先 Service 层的一些通用能力下沉到这一层，比如与缓存和存储交互策略，中间件的接入；其二，你也可以在这一层封装对第三方接口的调用，比如调用支付服务，调用审核服务等。
• DAO 层：数据访问层，与底层 MySQL、Oracle、Hbase 等进行数据交互。
• 外部接口或第三方平台：包括其它部门 RPC 开放接口，基础平台，其它公司的 HTTP 接口。

在这个分层架构中主要增加了 Manager 层，它与 Service 层的关系是：Manager 层提供原子的服务接口，Service 层负责依据业务逻辑来编排原子接口。

以上面的例子来说，Manager 层提供创建用户和获取用户信息的接口，而 Service 层负责 将这两个接口组装起来。这样就把原先散布在表现层的业务逻辑都统一到了 Service 层， 每一层的边界就非常清晰了。
除此之外，分层架构需要考虑的另一个因素，是层次之间一定是相邻层互相依赖，数据的流转也只能在相邻的两层之间流转。

分层架构的不足
虽然分层架构有很多优势，但它也有不少缺陷，它最重要的一个缺陷就是增加了代码的复杂度。这是显而易见的，明明我们可以在接收到请求后直接查询和操作数据库，却偏偏在中间插入了多个层次，并且每个层次可能只是简单的做数据传递，有时候增加一个小小的需求也可能要修改一整个链路上的代码，这个时候如果还增加了同事的负担那一定是会引来不少吐槽的。
另外，如果我们把每个层级独立部署，那么层级之间通过网络来交互，在性能上就会有损耗。

实战案例：
项目结构：


manager层：

service层调用manager层