开发&测试必须知道的 10种 常见软件架构模式

 

你是否想知道企业大规模系统是如何设计的?

在软件开发开始之前,我们必须选择一个合适的架构,能提供所需的功能和质量特性。因此,在将架构应用到我们的设计之前,我们应该了解各种不同架构的特点。

图片

01 什么是架构模式

根据维基百科:
架构模式是在软件架构上针对特定上下文件解决常见问题的通用、可复用的解决方案。架构模式与软件设计模式相似,但范围更广

在本文中,我将简要解释以下10种常见的体架构模式及其用法和优缺点:

  • 分层模式

  • 客户服务器模式(CS)

  • 主从模式

  • 管道过滤器模式

  • 代理模式

  • P2P模式

  • 事件总线模式

  • MVC模式

  • 黑板模式

  • 解释器模式

01 分层模式

此模式可用于构造可分解为子任务组的程序,每个子任务组处于特定的抽象级别。每一层都为下一层提供服务。

信息系统中常见的四层模式如下:

  • 表示层(也称为UI层)

  • 应用层(也称服务层)

  • 业务逻辑层(也称领域层)

  • 数据访问层(也称持久化层)

用途:
  • 通用桌面应用

  • 电子商务应用

    图片

    分层模式

02 客户端服务器模式

这个模式由两部分组成:一个服务器多个客户端。服务器组件将为多个客户端组件提供服务。客户端向服务器请求服务,服务器向这些客户端提供相关服务。此外,服务器继续侦听客户机请求。

用途:

在线应用程序,如电子邮件,文档共享和银行应用。

图片

客户服务器模式

03 主从模式

这个模式由两部分组成:master 和 slaves。master组件将工作分配给相同的slave组件,并根据slave组件返回的结果计算最终结果。

用途:
  • 在数据库复制中,将主数据库视为中心负责写数据,从数据库与主数据库同步

  • 连接到计算机系统总线上的外设(主驱动器和从驱动器)

    图片

    CS模式

04 管道过滤器模式

此模式可用于创建流数据处理系统。每个处理步骤都包含在一个过滤器组件中。要处理的数据通过管道传递。这些管道可用于缓冲或同步目的。

用途:
  • 编译器

    连续的过滤器分别执行:词法分析、解析、语义分析和代码生成

  • 信息处理工作流

    图片

    管道过滤器模式

05 代理模式

此模式结合解耦组件构造分布式系统。这些组件可以通过远程服务调用,相互交互。代理组件负责协调组件之间的通信。服务器将其功能(服务和特征)发布到代理。客户端向代理请求服务,然后代理根据注册中心将客户端请求重定向到合适的服务。

用途:

消息代理软件,如Apache ActiveMQ、Apache Kafka、RabbitMQ、JBoss Messaging

图片

代理模式

06 P2P模式

在此模式中,单个组件称为对等组件peer。对等组件既可以作为客户端向其他对等组建请求服务,也可以作为服务器向其他对等组件提供服务。对等组建可以充当客户端或服务器,也可以同时充当两者,它可以随时间动态地更改其角色。

用途:
  • 文件共享网络比如Gnutella和G2

  • 基于加密货币的产品,如比特币和区块链

    图片

    P2P模式

07 事件总线模式

该模式主要处理事件,有4个主要组件:事件源、事件监听器、通道和事件总线。事件源将消息发布到事件总线上的特定通道。侦听器订阅特定的通道。当消息发布到它们订阅过的通道时,侦听器会得到通知。

用途:
  • 安卓开发

  • 通知服务

图片

事件总线模式

08 MVC模式

(model-view-controller)这种模式,将交互式应用程序分为3个部分:
  • 模型:包含核心功能和数据

  • 将信息显示给用户(可以定义多个视图)

  • 处理来自用户的输入

这样做是为了将信息的内部表示与信息呈现给用户和从用户接受信息的方式分离开来。它解耦了组件,并允许高效的代码重用。

用途:
  • 大部分编程语言都使用的web开发架构

  • Web框架,如Django和Rails

    图片

    MVC模式

09 黑板模式

这种模式在没有确定性解决策略的问题方面很有用。黑板模式由3个主要部分组成

  • 黑板:结构化的全局内存包含解决方案对象

  • 知识源:具有自己表示形式的专用模块

  • 控制组件:选择、配置和执行模块。

所有的组件都可以访问黑板。组件可以生成添加到黑板上的新数据对象。组件在黑板上寻找特定类型的数据,并通过与现有的知识源进行模式匹配来找到这些数据。

用途:
  • 语音识别

  • 车辆识别与跟踪

  • 蛋白质结构识别

  • 声纳信号解析

    图片

    黑板模式

10 解释器模式

此模式用于设计组件,该组件用于解释专用语言编写的程序。它主要规定了如何对程序行求值,这些程序被称为用特定语言编写的句子或表达式。其基本思想是为语言的每个符号都建立一个类。

用途:
  • 数据库查询语言,如SQL

  • 用于描述通信协议的语言

    图片

 

总结:

感谢每一个认真阅读我文章的人!!!

作为一位过来人也是希望大家少走一些弯路,如果你不想再体验一次学习时找不到资料,没人解答问题,坚持几天便放弃的感受的话,在这里我给大家分享一些自动化测试的学习资源,希望能给你前进的路上带来帮助。

软件测试面试文档

我们学习必然是为了找到高薪的工作,下面这些面试题是来自阿里、腾讯、字节等一线互联网大厂最新的面试资料,并且有字节大佬给出了权威的解答,刷完这一套面试资料相信大家都能找到满意的工作。

 

          视频文档获取方式:
这份文档和视频资料,对于想从事【软件测试】的朋友来说应该是最全面最完整的备战仓库,这个仓库也陪伴我走过了最艰难的路程,希望也能帮助到你!以上均可以分享,点下方小卡片即可自行领取。

  • 5
    点赞
  • 6
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
第一天 基于微软 .net框架的解决方案设计概述-从理论到实践 第一天将为大家全面介绍基于微软产品和框架的解决方案设计理念;比较各软件设计方法的利弊以及微软MSF流程概述;同大家探讨软件架构设计的思想。同时我们将对微软全部的服务器产品以及桌面产品的集成特性进行介绍。第一天的课程包括: ·软件开发模型选择:XP/MSF/CMMI/Agile ·深入浅出Microsoft Solution Framework和Microsoft Operation Framework ·微软产品集成方案概述:SQL/Exchange/IIS/LCS/MOM/SMS/Office ·面向对象(OOP)的软件设计思想 ·面向服务(SOA)的软件设计思想 ·收集信息和需求分析 ·使用UML建模 ·创建Use Case及应用场景 ·ORM(对象关系映射) ·从业务流程到架构模型 ·设计模式软件架构中的应用 第二天 实施软件架构设计-基于微软 第二天将为大家全面讲述基于微软产品和框架的解决方案设计过程。以三层体系架构(Windows DNA)模型和智能客户端模型为例介绍了在MSF流程下的软件架构设计过程;比较了不同IT基础结构对软件架构设计的影响。探讨了软件架构设计中的常见问题,如:技术可行性分析、三层体系结构的设计要点、测试、发布以及安全问题。第二天的课程包括: ·软件设计文档编写 ·立项阶段架构师的工作 ·使用MSF与MOF结合覆盖软件生命周期 ·软件概念设计 ·软件物理设计 ·基于Windows Form的软件表现层设计 ·基于Web界面的软件表现层设计 ·在表示层中使用MVC与UIP · · ·在设计中使用事件驱动模型 ·在设计中使用数据驱动模型 ·Microsoft Enterprise Library在架构设计中的实际作用 ·Web服务和XML在架构设计中的实际作用 ·服务器还是客户端?Web 2.0和Web 1.0的比较 ·合理化物理设计 ·软件架构设计的优化 ·数据访问设计的优化 ·用户界面设计的优化 ·设计安全的软件架构以及安全策略的制定 ·在实施设计时使用测试驱动 ·软件模块的重用与重构 ·软件的部署和稳定化 第三天 设计实战-案例分析 第三天老师将和大家分享亲自带领团队进行开发的案例,包括成功案例分析和失败案例分析;将和大家详细讨论软件架构设计对项目实施的影响以及实际工程中应该注意的问题;同时将同大家分享模块重用和使用开源项目进行开发容易遇到的实际问题:安全、本地化、重构等等。第三天的课程包括: · ·软件架构安全实战 ·软件架构性能调优 ·案例:困难重重的手机智能更新系统 ·案例: 概述 软件构架(Architecture)是软件工程中发展迅速的一个研究实践领域。根据教育部关于紧缺人才报告,
目录   译者序   第2版前言   第1版前言   第0章不可知和不可说   0.1和解析体验相关的问题   0.1.1解析模式的冲突   0.1.2检测解析模式   0.1.3思考不准确的思想   0.2沟通的不可能性   0.2.1内部重新组织   0.2.2触及共享体验   0.2.3管理不完美的沟通   0.3聆听的三个层次   0.3.1三个层次和方法集   0.3.2三个层次与本书   0.3.3守-破-离   0.4那么,明天我做什么   第0A章不可知和不可说:演进   0A.1沟通和共享的体验   0A.2守-破-离   第1章创造和沟通的合作博弈   1.1软件和诗歌   1.2软件与博弈   1.2.1博弈的类型   1.2.2软件与攀岩   1.2.3创造和沟通的博弈   1.2.4软件与工程化   1.2.5软件与模型构建   1.3再论合作博弈   1.3.1程序员成为沟通专家   1.3.2更快地博弈   1.3.3标识物和道具   1.3.4减少回报   1.3.5对于首要目标的充分度   1.3.6对于积淀的充分度   1.3.7博弈中的博弈   1.3.8开放源码开发   1.4这对我意味着什么   第1A章创造和沟通的合作博弈:演进   1A.1沼泽游戏   1A.2合作中的竞争   1A.3其他领域的合作博弈   1A.4软件工程的重建   1A.4.1这一词汇从哪里来   1A.4.2我们从哪里走错了   1A.4.3重建软件工程   1A.4.4技艺   1A.4.5合作博弈   1A.4.6精益制造   1A.4.7重建后的软件工程   1A.4.8其他工程化中的协作   第2章个人   2.1人是古怪的   2.1.1寻找特征函数   2.1.2古怪性格的元素   2.1.3不可避免的多样性   2.1.4技术的作用   2.1.5相互冲突的共同点   2.2克服失败模式   2.2.1犯错误   2.2.2宁可失败也要选择保守   2.2.3创新而不研究   2.2.4不能始终如一的习惯动物   2.2.5使用纪律和容忍来应对   2.3以一些更好的方式工作   2.3.1具体化   2.3.2实物   2.3.3在某些东西的基础上进行修改   2.3.4观察和聆听   2.3.5支持专注和沟通   2.3.6工作分配要与个性相匹配   2.3.7天赋   2.3.8奖励要能保留乐趣   2.3.9组合奖励   2.3.10反馈   2.4利用成功模式   2.4.1善于四处寻找   2.4.2人们学习   2.4.3可塑性   2.4.4贡献和采取主动   2.4.5组合成功模式   2.4.6英雄也是普通人   2.5明天我该做什么   第2A章个人:演进   2A.1策略平衡   第3章团队的沟通与合作   3.1信息的对流   3.1.1延迟和机会损失成本   3.1.2尔格-秒   3.1.3渗透式沟通   3.1.4穿堂风   3.1.5信息辐射源   3.1.6热空气理论的应用   3.2跨越沟通的鸿沟   3.2.1沟通的形态   3.2.2去掉某些形态所产生的影响   3.2.3利用各形态   3.2.4黏度与跨越空间的鸿沟   3.3团队就是集体   3.3.1友善和冲突   3.3.2工作时间的公民意识   3.3.3敌意的XP与友善的XP   3.3.4使用胜利来建立“团队”   3.3.5团队文化与亚文化   3.4团队就是生态系统   3.5我明天该做什么   第3A章团队:演进   3A.1一个修订后的办公室布局样本   第4章方法集   4.1一个交付软件的生态系统   4.2方法集中的概念   4.2.1结构术语   4.2.2范围   4.2.3概念术语   4.2.4发布一个方法集   4.3方法集的设计原则   4.3.1常见设计错误   4.3.2在方法集上成功的项目   4.3.3与作者的相关性   4.3.4七条原则   4.4细看XP   4.4.1XP简介   4.4.2剖析XP   4.4.3调整XP   4.5到底为什么使用方法集   4.5.1方法集解决什么问题   4.5.2如何评估一个方法集   4.6明天我应该做什么   第4A章方法集:演进   4A.1方法集与策略   4A.2组织级的方法集   4A.3过程就是循环   4A.4更简单地描述方法集   第5章敏捷与自适应   5.1轻但足够   5.1.1刚好足够   5.1.2对于编制文档的建议   5.2敏捷   5.2.1最佳击球点   5.2.2虚拟团队的麻烦   5.3变得自适应   5.3.1不厌其烦地进行反思   5.3.2方法集成长技术   5.3.3反思研讨会技术   5.4明天我该做什么   第5A章敏捷与自适应:演进   5A.1对于寓意的误解   5A.1.1迭代必须简短   5A.1.2敏捷团队必须驻扎在一起   5A.1.3敏捷团队不需要计划   5A.1.4架构已死;重构是你全部所需要的   5A.1.5我们不需要什么经理   5A.1.6敏捷开发在纪律上要求很低   5A.1.7敏捷只适合最优秀的开发人员   5A.1.8敏捷是既老又新的、失败的、没有尝试过的   5A.2敏捷方法集的演进   5A.2.1XP第2版   5A.2.2Scrum   5A.2.3实用主义和无名的   5A.2.4可预测、计划驱动和其他中心调整   5A.2.5约束理论   5A.2.6精益开发   5A.3新的方法集话题   5A.3.1敏捷项目管理   5A.3.2测试   5A.3.3用户体验设计   5A.3.4规划管控、Burn图和系统工程   5A.3.5用例和用户故事   5A.4经久不绝的问题   5A.4.1最佳击球点和下降   5A.4.2固定价格、固定范围的合同   5A.4.3敏捷、CMMI和ISO9001   5A.4.4何时停止建模   5A.4.5高科技/高接触的工具箱   5A.4.6敏捷的中心   5A.4.7你有多敏捷   5A.4.8引入敏捷   5A.5软件开发之外的敏捷   5A.5.1项目组合管理   5A.5.2客户关系   5A.5.3合同   5A.5.4将变更引入组织   5A.5.5程序员读哈佛商业周刊   5A.5.6建造房屋   5A.5.7机场建设   5A.5.8图书出版   5A.5.9会议组织和敏捷模型的限制   第6章Crystal方法集   6.1对Crystal家族塑形   6.1.1核心Crystal元素   6.2CrystalClear   6.2.1CrystalClear的简要描述   6.2.2CrystalClear的反思   6.3CrystalOrange   6.3.1CrystalOrange的简要描述   6.3.2CrystalOrange的反思   6.4CrystalOrangeWeb   6.4.1CrystalOrangeWeb的简要描述   6.4.2CrystalOrangeWeb的反思   6.5明天我该做什么   第6A章Crystal方法集:演进   6A.1Crystal基因代码   6A.1.1合作博弈的理念   6A.1.2方法集的重点   6A.1.3方法集设计原则   6A.1.4高度成功的项目的7个特性   6A.1.5技术与选择   6A.1.6样本方法集设计   6A.2CrystalClear   6A.3把CrystalClear扩展到Yellow   附录A敏捷软件开发宣言   附录Aa敏捷软件开发宣言和相互依赖声明   附录BNaur、Ehn、宫本武藏   附录BaNaur、Ehn、宫本武藏:演进   附录C后记   参考文献

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值