软件架构原则之“分层架构”小结

分层架构（layered architecture）是最常见的软件架构，也是事实上的标准架构。

如果你不知道要用什么架构，那就用它，可以用在业务上也可以用在技术上。这种架构将软件分成若干个水平层，每一层都有清晰的角色和分工，不需要知道其他层的细节，层与层之间隔离通过接口通信，串行依赖。

分层架构

核心点：

1. 单向依赖，一层只依赖一层，不跨层
2. 抽象隔离，分的越开越好，哪怕是异地

好处：

1. 代码结构清晰易于理解
2. 代码复杂度降低，容易理解和开发
3. 层间隔离，利于排查问题
4. 后期的维护升级方便而简单
5. 每一层都可以独立测试，其他层的接口通过模拟解决
6. 不同技能的程序员可以分工，负责不同的层
7. 天然适合大多数软件公司的组织架构
8. 抽象逻辑复用起来简单

分层思想的真理：

计算机科学领域任何问题，都可以间接的通过添加一个中间层来解决。

分层采用的方法：

1. 单个项目的可采用package方式

com.xxx.core
-- .service
-- .mapper
-- .util
-- .controller
-- .dao
-- .model

1. 多层项目的采用引入独立jar方式

paper-parent
-- paper-common
-- paper-core
-- paper-core-api
-- paper-core-service
-- paper-rest

1. 微服务式分层

企业架构
-- 基础服务层：用户、订单、认证等
-- 应用层：各产品分离
-- 等等

分层介绍

Web型项目的B/S架构中经典分层策略“MVC架构”。这种架构一般的现在工具类的项目中，View采用java渲染引擎JSP（VelocityFreemakerThyemleaf等），但是主流的互联网平台都是前后端分离型项目，前端是独立构建和发布模式（npm大前端趋势），后端以接口方式提供服务。

干货分享：目前正在使用的分层架构图，欢迎讨论

表现层

有时候也说是客户端层，不论是App还是Web或者其他，指客户直接接触到的页面。Web前端架构后期会单独来详细介绍，这里就一笔带过了。

接口层

1. 采用Service提供RPC接口服务
2. 通过Web封装成Http接口服务

靠谱说绝大多数公司就两种服务形式：RPC 和 HTTP。统一规范的返回结果和异常的全局处理是必不可少的。这层不可以抛出异常，否则会导致client会出现不可控的错误，通过标准的ErrorCode&ErrorMeg提示，一般还会有流量控制和权限等控制监控在这层。

服务层（业务）

所有的业务实现放在这层，一般可以按照业务类型分类也便于识别管理；事务也放在这层，一般推荐只放在这层统一管理。

业务层所负责的：

1. 处理应用程序的业务逻辑和业务校验。
2. 管理事务。
3. 提供与其他层相互作用的接口。
4. 管理业务层级别的对象的依赖。
5. 在表示层和持久层之间增加一个灵活的机制，使得他们不直接联系在一起。
6. 通过揭示从表示层到业务层之间的上下文来得到业务逻辑。
7. 管理程序的执行（从业务层到持久层）。

持久层

主要有数据库的entity映射类，只提供简单CRUD的dao操作类，接口mapper类，一些连接中间件的封装util工具类；这层推荐严格禁止事务，异常可以统一封装一个OrmException对服务层提供。

数据层（存储）

数据层指存储，根据业务选择的数据存储基础设施，传统的关系型数据库Mysql、Oracle，Nosql数据库Redis、ES、Mongodb等。不同的数据库采用的connect方式不同，需要在持久层独立封装一个独立Util类进行集中管理。

dubbo项目的分层结构：

推荐

作者: Owen Jia，他的博客：Owen Blog

转载请著名作者所有权