应用分层, 系统各部分得以独立发展，更加灵活、可扩展和易维护

幸福，不是长生不老，不是大鱼大肉，不是权倾朝野。幸福是每一个微小的生活愿望达成。当你想吃的时候有得吃，想被爱的时候有人来爱你

应用分层是一种常见的软件设计模式，将整个应用程序分解成若干个层次结构，并将每个层次结构分配特定的职责。常见的分层结构包括DAO层、Service层、Manager层、Web层和开放接口层等。

DAO层：数据访问层，负责与底层数据库进行交互；
Service层：业务逻辑服务层，负责实现具体的业务逻辑，并调用DAO层进行数据操作；
Manager层：通用业务处理层，负责协调不同的Service层，提供缓存方案、中间件通用处理等通用能力；
Web层：接收HTTP请求，进行参数校验和路由转发，调用Manager层处理业务逻辑，并将结果返回给客户端；
开放接口层：封装Service方法，暴露成RPC接口或HTTP接口，处理异常，并返回结果。
通过应用封层，我们可以将应用程序分解成多个松耦合的层次结构，使得系统的各个部分可以独立发展，更加灵活、可扩展和易维护。同时，应用封层也能提高系统的可用性和用户体验，保证系统的稳定性和安全性。

hello

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

场景示例

一个简单的场景示例，以展示各个分层如何协同工作：

假设我们正在开发一个电商网站，其中有一个订单管理模块。订单管理模块需要提供如下功能：

• 创建订单
• 取消订单
• 查询订单详情
• 查询订单列表

我们将按照分层规定，分别实现如下的代码结构：

DAO层：

public interface OrderDao {
    void create(Order order);
    void update(Order order);
    void delete(long orderId);
    Order getById(long orderId);
    List<Order> getListByUserId(long userId);
}

Service层：

public interface OrderService {
    void createOrder(Order order) throws ServiceException;
    void cancelOrder(long orderId) throws ServiceException;
    Order getOrderById(long orderId) throws ServiceException;
    List<Order> getOrderListByUserId(long userId) throws ServiceException;
}

Manager层：

public interface OrderManager {
    void createOrder(Order order) throws ManagerException;
    void cancelOrder(long orderId) throws ManagerException;
    Order getOrderById(long orderId) throws ManagerException;
    List<Order> getOrderListByUserId(long userId) throws ManagerException;
}

Web层：

@RestController
@RequestMapping("/orders")
public class OrderController {

    @Autowired
    private OrderManager orderManager;

    @PostMapping
    public void createOrder(@RequestBody Order order) {
        try {
            orderManager.createOrder(order);
        } catch (ManagerException e) {
            // handle exception
        }
    }

    @DeleteMapping("/{orderId}")
    public void cancelOrder(@PathVariable("orderId") long orderId) {
        try {
            orderManager.cancelOrder(orderId);
        } catch (ManagerException e) {
            // handle exception
        }
    }

    @GetMapping("/{orderId}")
    public Order getOrderById(@PathVariable("orderId") long orderId) {
        try {
            return orderManager.getOrderById(orderId);
        } catch (ManagerException e) {
            // handle exception
            return null;
        }
    }

    @GetMapping
    public List<Order> getOrderListByUserId(@RequestParam("userId") long userId) {
        try {
            return orderManager.getOrderListByUserId(userId);
        } catch (ManagerException e) {
            // handle exception
            return null;
        }
    }
}

开放接口层：

public interface OrderRpcService {
    Order createOrder(Order order) throws RpcException;
    void cancelOrder(long orderId) throws RpcException;
    Order getOrderById(long orderId) throws RpcException;
    List<Order> getOrderListByUserId(long userId) throws RpcException;
}

以上是一个简单的示例，其中各个分层的职责如下：

• DAO层：负责与底层数据库交互，提供基本的CRUD操作；
• Service层：负责实现具体的业务逻辑，调用DAO层进行数据操作，并处理异常；
• Manager层：负责协调不同的Service层，处理多个DAO的组合复用，提供缓存方案、中间件通用处理等通用能力；
• Web层：负责接收HTTP请求，并进行参数校验和路由转发，调用Manager层处理业务逻辑，处理异常，并将结果返回给客户端；
• 开放接口层：负责将Service层封装成RPC接口，暴露给其他部门或者第三方平台调用，处理异常，并返回结果。

现在，我们可以通过如下方式将各个分层串联起来，完成电商网站订单管理模块的实现：

1. 客户端发送HTTP请求到Web层的接口；

2. Web层的接口进行参数校验和路由转发，将请求转发给OrderController中对应的方法；

3. OrderController中的方法调用OrderManager的对应方法，处理业务逻辑，并抛出ManagerException异常；除非有全局异常处理

4. OrderManager对异常进行捕获和处理，并将异常封装为ManagerException异常抛出；

5. OrderService对异常进行捕获和处理，并将异常封装为RpcException异常抛出；

6. 开放接口层的OrderRpcService对异常进行捕获和处理，并将异常封装为特定的错误码和错误信息，返回给客户端。

通过以上的分层结构，我们可以将电商网站订单管理模块进行灵活的组合和扩展，实现高性能、高可靠的订单管理服务。同时，各个分层职责明确，耦合度低，便于测试和维护。

其实Manager层组合Service也罢, 组合Dao层也好, 都是起到一个组合的中间层

异常全局处理

如果Controller中抛出ManagerException异常，客户端无法理解这个异常的含义，所以需要对异常进行全局处理。常见的做法是在Web层中增加一个异常处理器，将所有的异常统一处理，并返回友好的错误信息。

例如，我们可以定义一个全局异常处理器类，如下所示：

@ControllerAdvice
public class GlobalExceptionHandler {

    @ExceptionHandler(Exception.class)
    @ResponseBody
    public ResponseEntity<ErrorResponse> handleException(Exception e) {
        ErrorResponse errorResponse = new ErrorResponse();
        errorResponse.setCode(HttpStatus.INTERNAL_SERVER_ERROR.value());
        errorResponse.setMessage("系统繁忙，请稍后再试");

        if (e instanceof ManagerException) {
            // 如果是ManagerException异常，将异常信息封装到ErrorResponse中
            ManagerException managerException = (ManagerException) e;
            errorResponse.setCode(managerException.getCode());
            errorResponse.setMessage(managerException.getMessage());
        } else if (e instanceof ServiceException) {
            // 如果是ServiceException异常，将异常信息封装到ErrorResponse中
            ServiceException serviceException = (ServiceException) e;
            errorResponse.setCode(serviceException.getCode());
            errorResponse.setMessage(serviceException.getMessage());
        } else if (e instanceof RpcException) {
            // 如果是RpcException异常，将异常信息封装到ErrorResponse中
            RpcException rpcException = (RpcException) e;
            errorResponse.setCode(rpcException.getCode());
            errorResponse.setMessage(rpcException.getMessage());
        }

        return ResponseEntity.status(HttpStatus.INTERNAL_SERVER_ERROR).body(errorResponse);
    }
}

在这个异常处理器中，我们首先判断异常的类型，如果是ManagerException、ServiceException或RpcException异常，则将异常信息封装到一个ErrorResponse对象中，并返回给客户端。如果是其他类型的异常，则将默认的错误信息封装到ErrorResponse中，并返回给客户端。

通过这种方式，我们可以对异常进行全局处理，将异常信息封装成友好的错误信息返回给客户端，提高系统的可用性和用户体验。