代码分层设计
代码分层设计
在搭建一个项目之前，除了要进行架构和业务方面的设计和分析，往往还需要对代码的结构进行规范化设计。而分层思想，是应用系统最常见的一种架构模式。
我们会将系统进行横向切割，根据业务职责划分，这就是代码分层。
这样划分的目的是规范软件系统的逻辑结构，以便于后期开发和维护。
一个软件系统就像一幅传世名画，在色彩和线条的表面之下，是精妙的几何结构。
席里柯的《梅杜莎之筏》，画高五米，宽超七米，结构宏伟，气势磅礴，人体的塑造坚实而有力。尤其是它的画面上，由十几个人构成了两个金字塔式的几何图形。这些就是古典主义的特色。
上面是题外话，下面继续介绍代码分层。
我们熟悉的MVC(Model-View-Controller，分别是模型层、视图层、控制层)三层架构就是非常典型的分层架构模式。
它将页面和业务逻辑分离，提高应用的可扩展性及可维护性。
MVC 三层架构只是概念层面的指导思想，如果想要让开发更规范、职责更明确、层次更清晰，需要下面更为细致的代码分层设计。
在介绍代码的分层之前，需要先了解代码分层结构中的领域模型。
领域模型
下面介绍几个常用的领域模型，其中参考了阿里巴巴编码规范的设计。
DO
DO（Data Object）与数据库表结构一一对应，通过 DAO 层向上传输数据源对象。
DTO
DTO（Data Transfer Object）是远程调用对象，它是 RPC 服务提供的领域模型。
需要注意的是，对于 DTO 一定要保证其序列化，实现 Serializable 接口，并显示提供serialVersionUID，否则在反序列化时，如果 serialVersionUID 被修改，那么反序列化会失败。
BO
BO（Business Object）是业务逻辑层封装业务逻辑的对象，一般情况下，它是聚合了多个数据源的复合对象。
VO
VO（View Object） 通常是请求处理层传输的对象，它通过 Spring 框架的转换后，往往是一个 JSON 对象。
代码分层
在传统的MVC三层结构的基础之上，我们将业务系统设计为如下四层结构：前端层、请求处理层、业务逻辑层和持久层。
下面详细介绍一下各个分层的作用。
前端层
前端层的内容涵盖了从系统外发起的一切请求，还包括定时任务的触发配置，以及系统的监控和检测程序。
请求处理层
请求处理层的作用包括通过模板引擎(FreeMarket、Velocity等)的页面渲染、封装RESTful API的HTTP接口，以及暴露给前端调用的各种类型的接口。
业务逻辑层
业务逻辑层的职责是与数据持久层交互，包括对多个数据源的操作进行聚合，并且提供组合复用的能力。
如果网站采用分布式架构，或者数据库需要分库，也包括对RPC服务的统一调用，为了减少不必要的重复调用RPC服务，RPC Service中对数据进行统一处理以后再返回给Manager，是一个节省RPC连接的做法。
此外，它也是业务通用能力的处理层，其中还包括缓存方案、消息监听（MQ）、定时任务、参数校验、数据转换、异常处理等。
数据持久层
数据持久层承载了数据存储和访问的能力。包括通过DAO访问数据库的能力和通过DAP访问外部数据接口的能力。
良好的代码分层设计可以使代码的耦合性大大降低，易用性大大增强，为系统的微服务化和模块化拆分打下良好的基础。
文章被以下专栏收录
