您可以捐助,支持我们的公益事业。

1元 10元 50元





认证码:  验证码,看不清楚?请点击刷新验证码 必填



  求知 文章 文库 Lib 视频 iPerson 课程 认证 咨询 工具 讲座 Model Center   Code  
会员   
   
 
     
   
 
 订阅
系统分层架构的全面解析
 
作者:凌柚
  5224  次浏览      19 次
 2022-6-17
 
编辑推荐:
本文汇总了传统MVC架构、后端三层架构、阿里分层架构、DDD架构以及基于DDD架构的整洁架构和六边形架构。从前往后越来越复杂,其他也对应着软件工程的越来越复杂,架构模式也变的越来越复杂。希望能够帮助大家。
本文来自于CSDN ,由火龙果软件Linda编辑、推荐。

本文汇总了传统MVC架构、后端三层架构、阿里分层架构、DDD架构以及基于DDD架构的整洁架构和六边形架构。从前往后越来越复杂,其他也对应着软件工程的越来越复杂,架构模式也变的越来越复杂

软件架构领域没有一招鲜吃遍天的功法,针对的不同的业务场景采用不同的架构,并且随着业务的发展,不断调整架构以适应业务的发展,以变(架构、技术组件、重构等)应不变(业务发展、用户体验、稳定性等)才是一个合格的软件工程师应追求的境界。

1.为什么要分层?

分层架构是将软件模块按照水平切分的方式分成多个层,一个系统由多层组成,每层由多个模块组成。同时,每层有自己独立的职责,多个层次协同提供完整的功能。

如果系统没有分层,当业务规模增加或流量增大时我们只能针对整体系统来做扩展。分层之后可以很方便的把一些模块抽离出来,独立成一个系统,并且有如下的特点(好处):

高内聚:分层的设计可以简化系统设计,让不同的层专注做某一模块的事

低耦合:层与层之间通过接口或API来交互,依赖方不用知道被依赖方的细节

复用:分层之后可以做到很高的复用

扩展性:分层架构可以让我们更容易做横向扩展

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

2.传统MVC架构?

当我们实现一个应用程序时(不使用O/R Mapping),我们可能会写特别多数据访问层的代码,从数据库保存、删除、读取对象信息,而这些代码都是重复的。而使用ORM则会大大减少重复性代码。对象关系映射(Object Relational Mapping,简称ORM),主要实现程序对象到关系数据库数据的映射。

优点:关注前后端分离

缺点:模型层分层太粗,融合了数据处理、业务处理等所有的功能。核心的复杂业务逻辑都放到模型层,导致模型层很乱

适应场景:后端业务逻辑简单的服务,比如接口直接提供对数据库增删改查

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

视图V:展示数据 --用户界面 (视图,为用户提供使用界面,与用户直接进行交互。)

控制器C:处理用户的输入,解耦 --控制器 (控制器,用于将用户请求转发给相应的Model进行处理,并处理Model的计算结果向用户提供响应。)

作用:使用mvc的作用是将M和V进行分离,从而使同一个程序可以使用不同的表现形式,其实就是一组数据,可以分别用柱状图或者饼状图来进行展示

3.后端三层架构?

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

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

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

优点:逻辑与数据层分离

缺点:模型层分层比较粗,核心的复杂业务逻辑都放到模型层,导致模型层很乱

适应场景:后端业务逻辑简单的服务,比如接口直接提供对数据库增删改查

4.后端三层架构和MVC的区别与联系?

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

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

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

5.阿里四层分层架构?

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

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

这一层有两个作用:

一、可以将原先 Service 层的一些通用能力下沉到这一层,比如与缓存和存储交互策略,中间件的接入;

二、也可以在这一层封装对第三方接口的调用,比如调用支付服务,调用审核服务等RPC接口。

特点:添加了Manager 通用业务处理层。

优点:相比于三层方式,添加了通用处理层对接外部平台。 上下游对接划分的比较清晰

缺点:核心业务逻辑层没有划分

适应场景:业务逻辑不复杂的常用业务

另外一种讲解方法:

通用业务处理层,它有如下特征:

对第三方平台封装的层,预处理返回结果及转化异常信息。

对Service层通用能力的下沉,如缓存方案、中间件通用处理。

与DAO层交互,对多个DAO的组合复用。

其各层的作用如下:

终端显示层:各端模板渲染并执行显示的层。当前主要是Velocity渲染,JS渲染, JSP渲染,移动端展示等。

开放接口层:将Service层方法封装成开放接口,同时进行网关安全控制和流量控制等。

Web层:主要是对访问控制进行转发,各类基本参数校验,或者不复用的业务简单处理等。

Service层:业务逻辑层。

Manager层:通用业务处理层。

DAO层:数据访问层,与底层 MySQL、Oracle、HBase 等进行数据交互。

外部接口或第三方平台:包括其它部门RPC开放接口,基础平台,其它公司的HTTP接口。

6.DDD分层架构?

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

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

一、特点:

数据、缓存等都视为3基础层, 可以被所有层调用

抽离了领域层,负责核心业务逻辑处理,领域层调用外部依赖全部通过接口,以保证领域层的100%单测覆盖率

应用层聚合多个领域层的能力,只做功能的组合、转发,不负责具体业务逻辑

优点:相比于三层方式,更关注领域服务,即业务核心逻辑的划分、收敛

缺点:分层复杂, 如果业务逻辑简单没有必要

适应场景:业务复杂的业务

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

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

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

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

二、和传统三层架构的对比

DDD四层架构也基于传统三层架构的,不同点有以下几方面:

关注点不一样:三层架构关注请求调用顺序;DDD架构关注领域服务。

横向划分方式不一样:三层架构主要关注纵向划分,对横向划分没有约定;DDD架构更关注纵向,即:多个领域层之间划分及交互方式。

对资源的定位不一样:三层架构把所有依赖的数据都放到数据访问层;DDD架构只将领域强关联的数据放到Repository中,其他比如API层缓存、文件等都当成基础服务来处理。

7.整洁架构和六边形架构?

整洁架构和六边形架构都是DDD架构的一种方式,只不过是视角不同。

(1)整洁架构

特点:整洁架构的层就像洋葱片一样,它体现了分层的设计思想

整洁架构最主要的原则是依赖原则,它定义了各层的依赖关系,越往里依赖越低,代码级别越高,越是核心能力。外圆代码依赖只能指向内圆,内圆不需要知道外圆的任何情况。

(2)六边形架构

六边形架构又名“端口适配器架构”。追溯微服务架构的渊源,一般都会涉及到六边形架构。

六边形架构的核心理念是:应用是通过端口与外部进行交互的。我想这也是微服务架构下API网关盛行的主要原因吧。

也就是说,在下图的六边形架构中,红圈内的核心业务逻辑(应用程序和领域模型)与外部资源(包括APP、Web应用以及数据库资源等)完全隔离,仅通过适配器进行交互。它解决了业务逻辑与用户界面的代码交错问题,很好地实现了前后端分离。六边形架构各层的依赖关系与整洁架构一样,都是由外向内依赖。

   
5224 次浏览       19
相关文章

企业架构、TOGAF与ArchiMate概览
架构师之路-如何做好业务建模?
大型网站电商网站架构案例和技术架构的示例
完整的Archimate视点指南(包括示例)
相关文档

数据中台技术架构方法论与实践
适用ArchiMate、EA 和 iSpace进行企业架构建模
Zachman企业架构框架简介
企业架构让SOA落地
相关课程

云平台与微服务架构设计
中台战略、中台建设与数字商业
亿级用户高并发、高可用系统架构
高可用分布式架构设计与实践

最新活动计划
MBSE(基于模型的系统工程)4-18[北京]
自然语言处理(NLP) 4-25[北京]
基于 UML 和EA进行分析设计 4-29[北京]
以用户为中心的软件界面设计 5-16[北京]
DoDAF规范、模型与实例 5-23[北京]
信息架构建模(基于UML+EA)5-29[北京]
 
 
最新文章
架构设计-谈谈架构
实现SaaS(软件及服务)架构三大技术挑战
到底什么是数据中台?
响应式架构简介
业务架构、应用架构与云基础架构
最新课程
软件架构设计方法、案例与实践
从大型电商架构演进看互联网高可用架构设计
大型互联网高可用架构设计实践
企业架构师 (TOGAF官方认证)
嵌入式软件架构设计—高级实践
更多...   
成功案例
某新能源电力企业 软件架构设计方法、案例与实践
中航工业某研究所 嵌入式软件开发指南
某轨道交通行业 嵌入式软件高级设计实践
北京 航天科工某子公司 软件测试架构师
北京某领先数字地图 架构师(设计案例)
更多...