软件架构原则之“分层架构”小结
分层架构（layered architecture）是最常见的软件架构，也是事实上的标准架构。
如果你不知道要用什么架构，那就用它，可以用在业务上也可以用在技术上。这种架构将软件分成若干个水平层，每一层都有清晰的角色和分工，不需要知道其他层的细节，层与层之间隔离通过接口通信，串行依赖。
分层架构
核心点：
- 单向依赖，一层只依赖一层，不跨层
- 抽象隔离，分的越开越好，哪怕是异地
好处：
- 代码结构清晰易于理解
- 代码复杂度降低，容易理解和开发
- 层间隔离，利于排查问题
- 后期的维护升级方便而简单
- 每一层都可以独立测试，其他层的接口通过模拟解决
- 不同技能的程序员可以分工，负责不同的层
- 天然适合大多数软件公司的组织架构
- 抽象逻辑复用起来简单
分层思想的真理：
计算机科学领域任何问题，都可以间接的通过添加一个中间层来解决。
分层采用的方法：
- 单个项目的可采用package方式
com.xxx.core
-- .service
-- .mapper
-- .util
-- .controller
-- .dao
-- .model
- 多层项目的采用引入独立jar方式
paper-parent
-- paper-common
-- paper-core
-- paper-core-api
-- paper-core-service
-- paper-rest
- 微服务式分层
企业架构
-- 基础服务层：用户、订单、认证等
-- 应用层：各产品分离
-- 等等
分层介绍
Web型项目的B/S架构中经典分层策略“MVC架构”。这种架构一般的现在工具类的项目中，View采用java渲染引擎JSP（VelocityFreemakerThyemleaf等），但是主流的互联网平台都是前后端分离型项目，前端是独立构建和发布模式（npm大前端趋势），后端以接口方式提供服务。
干货分享：目前正在使用的分层架构图，欢迎讨论
表现层
有时候也说是客户端层，不论是App还是Web或者其他，指客户直接接触到的页面。Web前端架构后期会单独来详细介绍，这里就一笔带过了。
接口层
- 采用Service提供RPC接口服务
- 通过Web封装成Http接口服务
靠谱说绝大多数公司就两种服务形式：RPC 和 HTTP。统一规范的返回结果和异常的全局处理是必不可少的。这层不可以抛出异常，否则会导致client会出现不可控的错误，通过标准的ErrorCode&ErrorMeg提示，一般还会有流量控制和权限等控制监控在这层。
服务层（业务）
所有的业务实现放在这层，一般可以按照业务类型分类也便于识别管理；事务也放在这层，一般推荐只放在这层统一管理。
业务层所负责的：
- 处理应用程序的业务逻辑和业务校验。
- 管理事务。
- 提供与其他层相互作用的接口。
- 管理业务层级别的对象的依赖。
- 在表示层和持久层之间增加一个灵活的机制，使得他们不直接联系在一起。
- 通过揭示从表示层到业务层之间的上下文来得到业务逻辑。
- 管理程序的执行（从业务层到持久层）。
持久层
主要有数据库的entity映射类，只提供简单CRUD的dao操作类，接口mapper类，一些连接中间件的封装util工具类；这层推荐严格禁止事务，异常可以统一封装一个OrmException对服务层提供。
数据层（存储）
数据层指存储，根据业务选择的数据存储基础设施，传统的关系型数据库Mysql、Oracle，Nosql数据库Redis、ES、Mongodb等。不同的数据库采用的connect方式不同，需要在持久层独立封装一个独立Util类进行集中管理。
dubbo项目的分层结构：
推荐
作者: Owen Jia，他的博客：Owen Blog
转载请著名作者所有权