软件架构分层,你的项目处于什么阶段?

简介: 软件架构分层,你的项目处于什么阶段?

前言

只要从事软件开发的工作,系统架构是必备知识。有朋友说可能会说,我只是一个搬砖的,怎么会接触到架构知识呢?其实,除了架构的设计者(也就是架构师),作为普通的开发者也是在时刻践行着系统架构的理论。毕竟,再好的架构,都需要码农去实施。只不过当你没有系统了解软件架构时,可能感知不到而已。

本篇文章就带大家系统的了解一下软件架构的分层,学习完毕,你就会明白,为什么系统要分层。同时,也能准确的看清楚目前自己系统中采用的是什么样的分层架构。

不采用架构分层,行不行?

首先我们来思考一个问题,如果一个系统不采用分层架构可不可以?这个问题就好像在问,代码中不使用设计模式行不行?答案当然是可以的。但不采用架构分层,会带来极大的未知风险,或者说代码极具熵增的特性。

作为一个初创软件,可能没有什么业务逻辑,没有什么用户量,而软件最主要的目标就是快速上线,实践商业模式。此时,可以不考虑分层。但随着业务逻辑的复杂,业务板块的增多,彼此之间就会出现错综复杂的依赖关系,随之就会产生的逻辑不清晰、可读性差,维护困难,改动一处动全身等问题。

什么是架构分层?

分层架构是将软件模块按照水平切分的方式分成多个层,一个系统由多层组成,每层由多个模块组成。同时,每层有自己独立的职责,多个层次协同提供完整的功能。比如,我们经常提到的MVC架构,就是一种非常典型非常基础的分层方式。

分层设计的本质其实就是将复杂问题简单化,基于单一职责原则让每层代码各司其职,基于“高内聚,低耦合”的设计思想实现相关层对象之间的交互。从而,提升代码的可维护性和可扩展性。

系统架构分层之后,往往需要达到以下目标:

  • 高内聚:分层设计可以简化系统设计,让不同层专注做某一模块的事;
  • 低耦合:层与层之间通过接口或API来交互,依赖方不用知道被依赖方的细节;
  • 复用:分层之后可以做到代码或功能的复用;
  • 扩展性:分层架构可以让代码更容易横向扩展

通讯领域的OSI参考模型

在计算机领域现有最典型的分层架构设计就是OSI参考模型和TCP/IP参考模型了。关于这个模型,我们在《一篇文章,只用看三遍,终生不忘网络分层! 》一文中已经详细介绍了。下面直接看一下相关的模型图:

image.png对于上述的三种分层模式,试想一下,如果没有分层,当一个业务或协议需要改变时,我们只能针对整个系统做修改或扩展。而分层之后,便可以很方便的把不同功能的模块抽离出来,修改对应的模块即可。而且不同层还可以被复用,只要确保按照这个层的协议来处理就可以了。

软件系统整体分层

以Java软件应用为例,整个软件系统也可进行分层,比如分为部署的硬件环境、操作系统、所需的中间件、承载业务的应用程序以及软件接入层。可通过下图进行整体了解:

image.png对于上述分层也产生了对应在职位,比如运维工程师、中间件工程师、产品经理、开发工程师、测试工程师等工种。而我们在实践过程中,接触最多,使用最多的分层要属应用软件层了,其次是中间件层。

下面我们就来看看针对应用软件层通常有哪些分层方式。

经典三层架构

三层架构(3-tier application) ,通常就是将整个业务应用划分为:表现层(UI)、业务逻辑层(BLL)、数据访问层(DAL)。

image.png表现层(UI),通俗讲就是展现给用户的界面,对应项目中的Web层包含Servlet和Controller等。

业务逻辑层(BLL):也称作领域层,负责系统业务逻辑的处理,对应项目中Service和ServiceImpl等。

数据访问层(DAL):该层所做事务直接操作数据库,针对数据的增添、删除、修改、更新、查找等,对应项目中的Dao。

在提出该分层架构的时代,多数系统往往较为简单,本质上都是一个单体架构(Monolithic Architecture)的数据库管理系统。这种分层架构已经是Client-Server架构的进化了,它有效地隔离了业务逻辑与数据访问逻辑,使得这两个不同关注点能够相对自由和独立地演化。

在开源技术框架中,表现层实现的代表作品是Struts1/2、Spring MVC,业务层实现的代表作品是Spring,持久层实现的代表作品是Hibernate和Mybatis。

MVC

MVC全名是Model View Controller,是模型(model)-视图(view)-控制器(controller)的缩写,一种软件设计典范,用一种业务逻辑、数据、界面显示分离的方法组织代码,将业务逻辑聚集到一个部件里面,在改进和个性化定制界面及用户交互的同时,不需要重新编写业务逻辑。MVC被独特的发展起来用于映射传统的输入、处理和输出功能在一个逻辑的图形化用户界面的结构中。

标准的MVC交互模型如下图:image.pngView:视图,为用户提供使用界面,与用户直接进行交互。

Model:模型,承载数据,对用户提交请求进行计算的模块。分为两类,一类称为数据承载Bean,一类称为业务处理Bean。数据承载Bean是指实体类,专门承载业务数据的,如Student、User等。而业务处理Bean则是指Service或Dao对象,专门用于处理用户提交请求的。

Controller:控制器,用于将用户请求转发给相应的Model进行处理,并处理Model的计算结果向用户提供响应。

从图中可以看到,标准的MVC中模型能主动推数据给视图进行更新(观察者设计模式,在模型上注册视图,当模型更新时自动更新视图),但在Web开发中模型是无法主动推给视图(无法主动更新用户界面),因为在Web开发是请求-响应模型。

Web MVC标准架构,如下图所示:

image.png在Web MVC模式下,模型无法主动推数据给视图,如果用户想要视图更新,需要再发送一次请求(即请求-响应模型)。MVC用于将web(UI)层进行职责解耦。

三层架构和MVC的区别与联系

MVC严格说是三层架构中的UI层,也就是说,MVC把三层架构中的UI层再度进行了分化,分成了控制器、视图、实体三个部分,控制器完成页面逻辑,通过实体来与界面层完成通话,而C层直接与三层中的BLL进行对话。

三层架构和MVC可以共存。三层架构是基于业务逻辑来分的,而MVC是基于页面来分的。MVC是表现模式(Presentation Pattern),三层架构是典型的架构模式(Architecture Pattern)。

三层架构的分层模式是典型的上下关系,上层依赖于下层。但MVC作为表现模式是不存在上下关系的,而是相互协作关系。即使将MVC当作架构模式,也不是分层模式。MVC和三层架构基本没有可比性,是应用于不同领域的技术。

阿里四层架构

三层架构实现比较简单,很多朋友可能觉得项目分层就应该如此,结果就是往往会出现一大堆的业务逻辑都堆砌在Service层中。而在《阿里巴巴 Java 开发手册 》中将原来的三层架构进一步细化,添加了Manager通用业务处理层。

Manager层可以将原Service层的一些通用能力进行下沉,比如与缓存和存储交互策略,中间件的接入;还可以封装对第三方接口的调用,比如调用支付服务,调用审核服务等RPC接口。image.png通用业务处理层,它有如下特征:

  • 对第三方平台封装的层,预处理返回结果及转化异常信息。
  • 对Service层通用能力的下沉,如缓存方案、中间件通用处理。
  • 与DAO层交互,对多个DAO的组合复用。

其各层的作用如下:

  • 终端显示层:各端模板渲染并执行显示的层。当前主要是Velocity渲染,JS渲染, JSP渲染,移动端展示等。
  • 开放接口层:将Service层方法封装成开放接口,同时进行网关安全控制和流量控制等。
  • Web层:主要是对访问控制进行转发,各类基本参数校验,或者不复用的业务简单处理等。
  • Service层:业务逻辑层。
  • Manager层:通用业务处理层。
  • DAO层:数据访问层,与底层 MySQL、Oracle、HBase 等进行数据交互。
  • 外部接口或第三方平台:包括其它部门RPC开放接口,基础平台,其它公司的HTTP接口。

系统工程结构

在学习了以上分层架构之后,下面来看一下针对分层在软件系统中的对照关系表:

image.png以上分层定义仅供参考。在上表中还多出了对外接口层和接入层。

对外接口层:所有对外的接口放在这层,不能包含任何业务逻辑,只数据对象的转换和异常的封装。

接入层:所有外部系统的依赖放在这层,好处是一旦外部系统接口修改,只需要在一处修改即可。

DDD分层架构

DDD是一种处理高度复杂领域的设计思想,试图分离技术实现的复杂性,同时围绕业务概念构建领域模型,提出的一种软件架构设计的方法论。

DDD分层架构将数据、缓存等都视为基础层, 可以被所有层调用;抽离了领域层,负责核心业务逻辑处理,领域层调用外部依赖全部通过接口,以保证领域层的100%单测覆盖率;应用层聚合多个领域层的能力,只做功能的组合、转发,不负责具体业务逻辑。

我们这里只做DDD分层架构的简单介绍,关于DDD概念不做过多拓展,相关架构模式可专门进行学习一下。看一下DDD分层的架构图:

image.png其中对应层的功能介绍如下:

接口层(Interfaces):该层包含与其他系统交互的所有内容,如Web服务器、RESTful接口。接口层处理传入数据的解释、校验、编解码、序列化操作,同时可以考虑引入专门的DTO(数据转换对象)来协助数据转换;

应用层(Application):该层负责驱动应用程序完成工作流程。很薄一层,协调多个领域对象(实体、聚合根、领域服务)实现服务编排和组合完成工作流,该层通常不应该包含具体业务逻辑。该层涉及:其他微服务RPC调用、微服务编排和组合、分布式事务实现、消息驱动事件的驱动、日志记录等。

领域层(Domain):该层是软件的核心,包含业务逻辑具体实现,包含实体、值对象、聚合、领域服务、仓储接口等领域对象内容,通常该层应该配备图示告知软件是如何工作的;

基础层(Infrastructure):包含网关、缓存、数据库存储、消息中间件、监控、应用程序服务等通用的技术和基础服务。基础层以不同方式支持到其他三层,促进各层间通信。配置文件、数据库Schema模式定义以及仓储接口实现都是基础结构的一部分;

DDD分层架构传统三层架构的比较

DDD四层架构也基于传统三层架构的,看一下它们之间的对照关系:image.pngDDD四层架构和传统三层架构有以下区别:

  • 关注点不一样:三层架构关注请求调用顺序;DDD架构关注领域服务。
  • 横向划分方式不一样:三层架构主要关注纵向划分,对横向划分没有约定;DDD架构更关注横向,即:多个领域层之间划分及交互方式。
  • 对资源的定位不一样:三层架构把所有依赖的数据都放到数据访问层;DDD架构只将领域强关联的数据放到Repository中,其他比如API层缓存、文件等都当成基础服务来处理。

关于DDD架构分层还有整洁架构和六边形架构两种形式,这里就不再拓展,感兴趣的朋友可自行查找相关资料进行学习。

小结

本篇文章为大家讲解了市面上常见的架构分层。分层架构的目的是通过关注点分离来降低系统的复杂度,同时满足单一职责、高内聚、低耦合、提高可复用性和降低维护成本。但分层架构同样也有一定的缺点,比如开发成本高、性能略低、可扩展性低等问题。实践中,可根据需要选择合适的分层架构。


目录
相关文章
|
2月前
|
消息中间件 监控 前端开发
如何开发项目管理系统中的项目结项板块?(附架构图+流程图+代码参考)
在企业项目管理中,“项目结项”是关键环节,常因流程不清、文档不全、审批滞后等问题导致交付困难。本文介绍如何通过“项目结项”模块实现线上化管理,涵盖结项申请、审批流程、成果上传、权限控制等功能,帮助团队高效完成项目收尾,避免成果丢失与流程混乱。内容包括功能设计、业务流程、系统架构、数据库设计、核心代码实现、前端交互及优化建议,助力项目管理系统快速落地并稳定运行。
|
1月前
|
人工智能 自然语言处理 JavaScript
Github又一AI黑科技项目,打造全栈架构,只需一个统一框架?
Motia 是一款现代化后端框架,融合 API 接口、后台任务、事件系统与 AI Agent,支持 JavaScript、TypeScript、Python 多语言协同开发。它提供可视化 Workbench、自动观测追踪、零配置部署等功能,帮助开发者高效构建事件驱动的工作流,显著降低部署与运维成本,提升 AI 项目落地效率。
180 0
|
2月前
|
数据挖掘 项目管理 Python
如何开发项目管理系统中的项目启动板块?(附架构图+流程图+代码参考)
本文介绍了项目管理系统中“项目启动”板块的设计与实现,涵盖功能模块、业务流程、开发技巧及效果展示,并提供代码参考和常见问题解答,助力企业高效搭建项目管理平台。
|
2月前
|
存储 Java 数据库连接
简单学Spring Boot | 博客项目的三层架构重构
本案例通过采用三层架构(数据访问层、业务逻辑层、表现层)重构项目,解决了集中式开发导致的代码臃肿问题。各层职责清晰,结合依赖注入实现解耦,提升了系统的可维护性、可测试性和可扩展性,为后续接入真实数据库奠定基础。
252 0
|
2月前
|
缓存 Java 数据库
Java 项目分层架构实操指南及长尾关键词优化方案
本指南详解基于Spring Boot与Spring Cloud的Java微服务分层架构,以用户管理系统为例,涵盖技术选型、核心代码实现、服务治理及部署实践,助力掌握现代化Java企业级开发方案。
142 2
|
2月前
|
监控 前端开发 BI
如何开发项目管理系统中的项目收支板块?(附架构图+流程图+代码参考)
本文深入讲解项目管理系统中项目收支模块的设计与实现,涵盖预算、收入与支出管理,以及报表分析功能。内容包括模块功能概述、业务流程、开发技巧与实现方法,并提供数据库设计及前后端代码示例,助力企业打造高效的项目财务管控系统。
|
2月前
|
SQL 前端开发 项目管理
如何开发项目管理系统中的项目执行板块?(附架构图+流程图+代码参考)
随着企业项目规模扩大,传统管理方式已难以满足需求。本文介绍项目管理系统中“项目执行”板块的开发,涵盖任务管理、创建、验收及进度汇报等核心环节。通过功能设计、业务流程和开发技巧,结合代码示例,帮助企业高效推进项目执行,提升管理效率。
|
6月前
|
资源调度 前端开发 算法
鸿蒙OS架构设计探秘:从分层设计到多端部署
本文深入探讨了鸿蒙OS的架构设计,从独特的“1+8+N”分层架构到模块化设计,再到智慧分发和多端部署能力。分层架构让系统更灵活,模块化设计通过Ability机制实现跨设备一致性,智慧分发优化资源调度,多端部署提升开发效率。作者结合实际代码示例,分享了开发中的实践经验,并指出生态建设是未来的关键挑战。作为国产操作系统的代表,鸿蒙的发展值得每一位开发者关注与支持。
|
3月前
|
设计模式 开发者
一、HarmonyOS Next 开发者手册项目之项目架构设计
该项目是一个基于HarmonyOS Next的开发者学习手册应用,旨在帮助开发者系统学习HarmonyOS开发知识。项目采用分级学习方式,从基础到高级逐步深入讲解技术与实践案例。前四章重点介绍应用架构相关内容,助力快速掌握应用核心。 项目结构清晰,包含主入口、源代码目录、公共资源和工具等。页面导航分为多个阶段:萌新小白(基础入门)、登堂入室(进阶学习)、进阶高手(高级开发)。支持Markdown解析,使用`@luvi/lv-markdown-in`插件展示内容,并定义了多种数据结构以规范开发流程。 源码已开源,持续更新中
86 1
|
10月前
|
前端开发 JavaScript 测试技术
Kotlin教程笔记 - 适合构建中大型项目的架构模式全面对比
Kotlin教程笔记 - 适合构建中大型项目的架构模式全面对比
133 3