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

分层架构(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

转载请著名作者所有权

相关推荐