如何理解《阿里巴巴 Java 开发手册》中的 Manager 层？

[halk]

在阿里巴巴 Java 开发手册里，建议的架构如下图：

- 开放接口层：可直接封装 Service 方法暴露成 RPC 接口；通过 Web 封装成 http 接口；进行网关安全控制、流量控制等。 
- 终端显示层：各个端的模板渲染并执行显示的层。当前主要是 velocity 渲染，JS 渲染，JSP 渲染，移动端展示等。 
- Web 层：主要是对访问控制进行转发，各类基本参数校验，或者不复用的业务简单处理等。 
- Service 层：相对具体的业务逻辑服务层。 
- Manager 层：通用业务处理层，它有如下特征：
<br>1 ） 对第三方平台封装的层，预处理返回结果及转化异常信息；
<br>2 ） 对 Service 层通用能力的下沉，如缓存方案、中间件通用处理；
<br>3 ） 与 DAO 层交互，对多个 DAO 的组合复用。
- DAO 层：数据访问层，与底层 MySQL、Oracle、Hbase 等进行数据交互。 
- 外部接口或第三方平台：包括其它部门 RPC 开放接口，基础平台，其它公司的 HTTP 接口。

应当如何理解Manager层呢，特别是上文提到的第三点与 DAO 层交互，对多个 DAO 的组合复用？

例如用户进行购物操作, 分别记录一条订单记录和操作记录，按照手册应该如此实现：

public class OrderService{

    @Autowired
    private OrderDao orderDao;

    @Autowired
    private OrderManager orderManager;

    .. save(Order order){
        orderManager.save(order);
    }
    .. detail(long orderId){
        return orderDao.get(orderId)
    }
}


public class OrderManager{

    @Autowired
    private OrderDao orderDao;

    @Autowired
    private LogDao logDao;

    .. save(Order order){
        orderDao.save(order);
        logDao.save(order.getLog())
    }
}

大家理解不一，举个更具体的业务例子：
用户下单，进行扣款，进行了以下处理：
a. 查询商品信息（不通过缓存）
b. 查询用户信息（通过缓存）
c. 查询优惠券信息（不通过缓存）
d. 创建订单
e. 更新优惠券使用
f. 更新库存（通过 RPC ）
-----------------

根据业务，可能有`Goods`\`Customer`\`Coupon`三个实体，DAO\Manager\Service 三层架构

那么根据阿里的开发手册，应当如何处理？

[pythonee]

我理解是用于管理接口的，比如运维管理、可用性管理等

[halk]

还有第二点又应该如何理解：`对 Service 层通用能力的下沉，如缓存方案、中间件通用处理`

[secondwtq]

讲个笑话：

Of course we need managers in companies, otherwise where does all the profit go?

[huijiewei]

进化后应该是 AOP

[loryyang]

我觉得这样理解：另外一个项目也需要使用到的一些通用的功能，不是本项目提供的服务，但是别的项目也能用的功能。是从 service 层往下沉淀的（从 service 层抽取出来的）
个人认为，对于小项目，完全没必要建立 manager 层，一层 service 足够了

[huangdayu]

我的理解是:manager 是公用的 service

[Foxkeh]

小弟认觉得此设计利于微服务架构，接口调用层次更清晰。具体看业务复杂程度和项目规模吧跟，小项目的话应该都不会细分 service 跟 manager

[qiyuey]

Manger 功能比较单一，如实体的增删改查，Service 是多个 Manger 的组合，实现一块相对独立的业务逻辑

[halk]

@qiyuey 反了吧？

[specita]

简单的 crud 不需要 manager 层的，如文档所说，比如我们项目有个 rpc 层，其实就是 manager 这个概念

[muzzy]

@halk 他的意思应该是由 manger 提供基础服务，由 service 进行服务整合串联业务逻辑。

[cyspy]

如果位于 Service 和 DAO 之间的话，处理的应该是类似热点缓存、外键约束这一类所有 service 通用的内容吧

[kanepan19]

事务在 manager 层，抛出异常。
Service 往往捕获异常，return 通过 Result 返回，比如 Result<Order>

[southsala]

举个栗子，如果你开发一个去掉 Manager 层和外部接口或第三方平台的教育 APP 后台，这个分层应该很容易理解。
后续你加个天气功能，加了 Manager 和外部接口部分，天气接口限制访问次数，所以在 Manager 层加了缓存；还有教育后台的某些数据的缓存（ 2 ）
之后要变现，买了个电商系统，于是 Manager 层对数据整理一下，比如异常提醒之类和本系统格式相左的，返回给上一级（ 1 ）
（ 3 ）的话大概是需要组合的通用数据，降低负责度

[halk]

更新了一个例子，请大家补充
谢谢

[HansCathy]

Manager 层 我理解是操作缓存 + 调用 DAO, 是一个综合的数据操作层

[YzSama]

@halk
OrderService 下单
a. 查询 goodsManager 商品信息 ( 不缓存 )
b. 查询 userManager 用户信息 (带缓存的方法 ，业务里面是通过 用户服务接口获取的用户信息。)
c. 查询 couponManager 优惠券信息 (不缓存)
d. create orderManager ( 通用的订单服务 )
e. update couponManager (更新优惠劵信息)
f. update by rpc.SKUManagerRPC 接口

我想的大概是这样。