精华内容
下载资源
问答
  • 应用架构
    千次阅读
    2021-11-28 08:55:52

    架构分类的-业务架构,应用架构,技术架构,数据架构

    LD is tigger forever,CG are not brothers forever, throw the pot and shine forever.
    Modesty is not false, solid is not naive, treacherous but not deceitful, stay with good people, and stay away from poor people.
    talk is cheap, show others the code and KPI, Keep progress,make a better result.
    Survive during the day and develop at night。

    目录

    概 述

    一、什么是架构
    把一个整体(完成人类生存的所有工作)切分成不同的部分(分工),由不同角色来完成这些分工,并通过建立不同部分相互沟通的机制,使得这些部分能够有机的结合为一个整体,并完成这个整体所需要的所有活动,这就是架构。

    边界划分:根据要解决的问题,对目标系统的边界进行界定。
    能力划分:对目标系统按某个原则的进行切分。切分的原则,要便于不同的角色,对切分出来的部分,并行或串行开展工作,一般并行才能减少时间。
    交互机制:并对这些切分出来的部分,设立沟通机制。
    根据3,使得这些部分之间能够进行有机的联系,合并组装成为一个整体,完成目标系统的所有工作
    二、架构的分类

    在这里插入图片描述

    业务(逻辑)架构:使用一套方法论对产品(项目)所涉及到的需求的业务进行业务边界划分,简单的讲就是根据一套逻辑思路进行业务的拆分,总体原则是对业务进行业务边界的划分,比如做一个企业订购服务网站,你需要把商品类目、商品、订单、订单服务、支付、退款很清晰的划分出来,而业务架构不需要考虑诸如我用什么技术开发、我的并发大怎么办、我选择什么样的硬件等等。
    在这里插入图片描述

    数据(持久化)架构:对存储数据(资源)的架构方法论,其架构原则同应用架构大同小异,即考虑到各个系统应用场景、不同时间段的应用场景对数据进行诸如数据异构、读写分离、数据库或NOSQL的策略、缓存的使用、分布式数据(数据库)策略等等。 数据架构主要解决三个问题:第一,系统需要什么样的数据;第二,如何存储这些数据;第三,如何进行数据架构设计。

    技术架构:应用架构本身只关心需要哪些应用系统,哪些平台来满足业务目标的需求,而不会关心在整个构建过程中你需要使用哪些技术。技术架构是应接应用架构的技术需求,并根据识别的技术需求,进行技术选型,把各个关键技术和技术之间的关系描述清楚。技术架构解决的问题包括:如何进行纯技术层面的分层、开发框架的选择、开发语言的选择、涉及非功能性需求的技术选择。

    另外还有安全架构等。

    总体来看,首先需要熟悉业务,形成业务架构,根据业务架构,做出相应的数据架构和应用架构,最后通过技术架构落地实施。业务架构是战略,应用架构是承上启下,一方面承接业务架构的落地,另一方面影响技术架构的选型。如何针对当前需求,选择合适的架构,如何面向未来,保证架构平滑过渡,这个是软件开发者,特别是架构师,都需要深入思考的问题。

    没有最优的架构,只有最合适的架构,一切系统设计原则都要以解决业务问题为最终目标,脱离实际业务的技术情怀架构往往是空中楼阁。

    小结

    架构分类:

    参考资料和推荐阅读

    1.链接: 参考资料.

    更多相关内容
  • 随着互联网的发展,网站应用的规模不断扩大,常规的应用架构已无法应对,分布式服务架构以及微服务架构势在必行,亟需一个治理系统确保架构有条不紊的演进。 单体应用架构 Web应用早期,很多项目都时以单体项目存在...

    系统架构演变

    随着互联网的发展,网站应用的规模不断扩大,常规的应用架构已无法应对,分布式服务架构以及微服务架构势在必行,亟需一个治理系统确保架构有条不紊的演进。

    单体应用架构

    Web应用早期,很多项目都时以单体项目存在,然后项目中分为Controller、Service、Dao层,将所有的功能模块都开发在一个项目中,进行打包和部署,当服务能力不够时,采用横向拓展的方式解决。

    在这里插入图片描述

    缺点:

    • 耦合性高,所有模块放在通一个项目中,使得各个模块的耦合性很高
    • 灵活性差,在某个模块需要横向拓展的时候,需要整个项目一起部署
    • 不易维护,部分模块代码发生修改,需要所有模块一起重新上线,另外整个项目的代码量较大,较为庞大

    垂直应用架构

    当访问量逐渐增大,单一应用横向拓展增加机器带来的加速收益越来越小,随之应运而生的是将应用拆成互不相干的几个应用,以提升效率。
    在这里插入图片描述

    缺点:

    • 全部功能集成在一个工程中,对于大型项目不易开发、扩展及维护。
    • 系统性能扩展只能通过扩展集群结点,成本高、有瓶颈。

    分布式SOA架构

    什么是SOA

    SOA 全称为 Service-Oriented Architecture,即面向服务的架构。它可以根据需求通过网络对松散耦合的粗粒度应用组件(服务)进行分布式部署、组合和使用。一个服务通常以独立的形式存在于操作系统进程中。

    站在功能的角度,把业务逻辑抽象成可复用、可组装的服务,通过服务的编排实现业务的快速再生,目的:把原先固有的业务功能转变为通用的业务服务,实现业务逻辑的快速复用。

    通过上面的描述可以发现 SOA 有如下几个特点:分布式、可重用、扩展灵活、松耦合。

    当垂直应用越来越多,应用之间交互不可避免,将核心业务抽取出来,作为独立的服务,逐渐形成稳定的服务中心,使前端应用能更快速的响应多变的市场需求。

    在这里插入图片描述

    优点:

    • 抽取公共的功能为服务,提高开发效率;
    • 对不同的服务进行集群化部署解决系统压力;
    • 基于ESB/DUBBO减少系统耦合。

    缺点:

    • 抽取服务的粒度较大;
    • 服务提供方与调用方接口耦合度较高(感觉这个是最主要的缺点)。

    微服务架构

    微服务架构和分布式SOA架构有一点类似,但是区别也很明显,SOA是面向服务的架构,从顶层的应用到底层的数据库设计都是基于应用来设计,但是微服务是将服务原子化,独立拆分成各个独立的系统。
    在这里插入图片描述

    优点:

    • 通过服务的原子化拆分,以及微服务的独立打包、部署和升级,小团队的交付周期将缩短,运维成本也将大幅度下降;
    • 微服务遵循单一原则。微服务之间采用Restful等轻量协议传输。

    缺点:

    • 微服务过多,服务治理成本高,不利于系统维护;
    • 分布式系统开发的技术成本高(容错、分布式事务等)。

    随着Spring Cloud全家桶不断深入引入,微服务这些缺点都得到了解决。

    分布式SOA架构和微服务架构对比

    SOA“面向服务的架构”:他是一种设计方法,其中包含多个服务,服务之间通过相互依赖最终提供一系列的功能。一个服务 通常以独立的形式存在与操作系统进程中。各个服务之间通过网络调用。

    微服务架构:其实和 SOA 架构类似,微服务是在 SOA 上做的升华,微服务架构强调的一个重点是“业务需 要彻底的组件化和服务化”,原有的单个业务系统会拆分为多个可以独立开发、设计、运行的小应用。 这些小应用之间通过服务完成交互和集成。

    功能分布式SOA架构微服务架构
    组件大小大块业务逻辑单独任务或小块业务逻辑
    耦合通常松耦合总是松耦合
    公司架构任何类型小型、专注于功能交叉团队
    管理着重中央管理着重分散管理
    目标确保应用能够交互操作执行新功能、快速拓展开发团队
    展开全文
  • 软件架构--MVC介绍(垂直应用架构

    千次阅读 2022-03-06 18:56:34
    软件架构--MVC介绍(垂直应用架构)1 介绍2 示例3 优势4 缺点参考 1 介绍 MVC(视图/模型结构)把数据和视图组件分离,这使得我们可以在几个不同的试图组件中显示相同的数据,并且实现新类型的视图,并且不改变底层...

    软件架构--MVC介绍(垂直应用架构)

    1 介绍

    MVC(视图/模型结构)把数据和视图组件分离,这使得我们可以在几个不同的试图组件中显示相同的数据,并且实现新类型的视图,并且不改变底层的数据结构。也可以根据控制响应的不同命令,在同一个组件区创建不同的视图样式,来加载不同的输入数据。为了更灵活的对用户输入进行处理,引入了delegate这个概念。它的好处是,数据项的渲染与编程可以进行定制。
    在这里插入图片描述

    • Model:model管理数据,负责数据的请求和更新
    • View:向用户展示数据
    • Controller:处理Model和View之间的交互。负责为View提供正确的数据,为Model提供来自View的操作请求。
      该模式降低耦合,多个View可以显示同一数据,View层不用担心数据层Model发生变化。
      在这里插入图片描述

    2 示例

    在这里插入图片描述
    在这里插入图片描述

    3 优势

    • 技术单一、学习成本低
    • 开发上手快
    • 测试、部署和运维简单

    4 缺点

    • 复杂应用的开发维护成本高,部署效率低,如全量编译和部署时长。
    • 团队效率差,部分公共功能重复开发,代码重复率居高不下。
    • 系统可靠性变差。随着业务的发展,访问量逐渐攀升,网络流量、负载均衡、数据库连接面临巨大压力。
    • 某节点故障,其他节点流量陡增,引起“雪崩效应”。
      维护和定制困难。物业代码膨胀,功能复杂,垂直架构模式下无法对复杂业务进行拆分,维护和定制都很困难。
    • 新功能上线周期变长。(1)公共API变更导致测试工作量激增。公共API变动,调用者都需要测试,引入大量回归测试工作量;(2)新特性无法独立部署和交付。新功能与老功能一起编译、大包和测试,这种强耦合导致交付效率下降。

    参考

    1、百科–MVC框架
    2、Qt 5.12–Model/View模型/视图(MVC)模式
    3、《分布式服务框架原理与实践》 作者 李林峰
    4、波澜壮阔的MVC发展史

    展开全文
  • 应用架构 应用架构(Application Architecture)是描述了IT系统功能和技术实现的内容。应用架构分为以下两个不同的层次: 企业级的应用架构:企业层面的应用架构起到了统一规划、承上启下的作用,向上承接了企业战略...

    应用架构

    应用架构(Application Architecture)是描述了IT系统功能和技术实现的内容。应用架构分为以下两个不同的层次:

    企业级的应用架构:企业层面的应用架构起到了统一规划、承上启下的作用,向上承接了企业战略发展方向和业务模式,向下规划和指导企业各个IT系统的定位和功能。在企业架构中,应用架构是最重要和工作量最大的部分,他包括了企业的应用架构蓝图、架构标准/原则、系统的边界和定义、系统间的关联关系等方面的内容。

    单个系统的应用架构:在开发或设计单一IT系统时,设计系统的主要模块和功能点,系统技术实现是从前端展示到业务处理逻辑,到后台数据是如何架构的。这方面的工作一般属于项目组,而不是企业架构的范畴,不过各个系统的架构设计需要遵循企业总体应用架构原则。

    应用架构主要以架构图的方式描述系统的组成和框架,一般从系统功能和系统技术层次两个架构视角进行设计:

    1. 系统功能视角的应用架构图

    ​​​​​

    2. 系统技术层次视角的应用架构图 

    业务架构

    ----摘自《自主变革的基石 制造企业管理技术及SOA实践》

        主要考虑部署,例如你不同的应用如何分别部署,如何支持灵活扩展、大并发量、安全性等,需要画出物理网络部署图。按照应用进行划分的话,还需要考虑是否支持分布式SOA

        每一个典型业务,都可以把它想象为一台运行中的机器,而其中的每个业务组件便是构成这台机器的功能模块。之所以要利用组件来进行业务架构的搭建,正是因为组件具有上述特性,这些特性能确保搭建的典型业务架构图,既完整有效、又无功能冗余,而且有利于今后展开系统架构的组件分析和设计。这样的架构能告诉我们:是由哪些内容相对独立的业务模块构成了这项典型业务。如对其中的每一个业务组件之间的作业关联关系、相互沟通的方式进行研究,就能掌握整个业务架构的协同作业水平;如果对每一个业务组件都采用前述外特性定义的方法加以描述,就能掌握这些组件当前能完成哪些独立的业务内容以及能达成哪些业务目标。本节重点介绍利用业务架构图分析典型业务的分析方法,分析的对象就是业务架构在功能构成方面的完整性和合理性。

       首先,需要表达出当前的典型业务是由哪些业务组件构成的。基本可以断言,大家在开始按上述三个层次描述某个典型业务的构成时,一定会对应该如何定义管理层和决策层的业务组件感到困惑,这是非常自然的反应。因为,至今以来,大家总是在研究执行层的作业方式,不会去、也不敢去研究管理层和决策层的作业能力。但在不远的将来,我们的企业注定要进入业务协同和系统整合的时代,所以,大家现在应该开始学习如何定义和建立管理层和决策层业务组件的具体方法了。

    典型的整车生产企业产品开发业务的业务架构示意图

     

       如典型的整车生产企业产品开发业务的业务架构示意图所示:当我们对于某项典型业务的业务组件的构成进行初步的归纳后,能够得到该项业务的一个整体的框架结构,我们可以称之为“业务架构图”,以及在这个框架内,企业中三个层级的员工在该项业务上分别从事着哪些作业内容。分析执行层的业务作业方式和作业规律,你觉得很正常,但如果让你去分析作为你上司的管理层、甚至决策层的作业方式和作业规律时,你也许会感到有所不安。这种心理反应,实际上正好反映出目前很多企业中的一种能力倒置现象的产生原因。很多人都了解这样的事实,那就是,企业中的很多升职后的中高层领导,在就位后的很长时间内,不能进入应有的管理角色中,这绝对不只是个人能力的差异问题,而主要是因为我们的中高层领导总是习惯地认为:研究执行层的作业方式和规律才是他们的主要职责,而没有注意到自己的作业内容和作业方式在整个作业链条中的重要作用,其结果,自然是管理层和决策层领导们的业绩,只好取决于执行层作业人员的努力程度,这种习惯也导致我们的中高层领导们不会去研究影响自己判断能力和决策能力的技术瓶颈是什么。而很多新出现的现代管理模式,实际上就是为了解决中高层领导们的作业能力问题,或是为了解决三个业务层级之间的信息沟通能力的问题,这也就是为什么业务架构分析人员还必须分析战略层和管理层作业形态的原因。下面将分别说明上述三个不同层次作业组件的特点:

    (1)战略层业务组件

       战略层业务组件自然是用于定义和规范战略层决策人员的业务行为的。那么,哪些人员可以归类于战略决策层之中呢?一般说来,在典型的制造企业中,部长以上的领导应被理解为企业战略决策人员,因为,他们通常已脱离具体的、单一的业务管理,他们通常会被要求在某个综合业务的专业领域提出战略性规划,并按规划进行部署和指挥。但在很多企业中,还设置有经营管理课或战略策划部等机构,其中的一些专门从事为决策层领导进行战略数据分析和提出具体方案的高级管理人员,也应该被认为是战略层业务组件中的业务人员。

     战略层业务组件通常应按如下的作业基准进行设计:

    - 对于特定的典型业务,是否具备有效的战略规划编制和调控能力。

    这里提到的调控能力,是指当企业经营发生重大的内部或外部环境变化时,企业内部是否具备能对既定规划及经营目标做出及时分析和调整的响应机制和具体的作业标准。

    - 制定、发布以及变更经营战略规划的流程和作业规则是否明确。

    这只是一个规范作业流程的问题,在很多企业内部,通常具有手工审批,进行传递的流程,有时存在指令重复、重要度不明、不易追溯等管理问题。

    - 是否能及时、准确地获取相关战略指标的动态统计数据(用于决策)。

    这是直接影响战略层决策能力的重要条件。这里提到的及时和准确,往往可以作为衡量一个企业管理技术水平的标尺。

    - 战略指标数据是否能明确指向具体部门或具体业务组件(用于能力评价)。

    这同样是一项检验企业管理技术水准的重要课题,在此后的第七和第八章中,将对此课题展开详细的讨论。

    - 是否具有根据设置的危机监控标准,及时触发决策机制的系统反应能力(确保决策的及时性)。

    这是一个技术含量最高的课题,任何企业都很难达到这样的水准,只有在管理方法和技术手段方面同时达到很高水准的企业,才能有效展开这一类课题的研究活动。但这一课题显然是所有企业都需要瞄准的目标。

       当然,上述的作业基准未必一定完整和精准,只是按照对一般指挥机构职能的理解来考虑的。例如,企业每年需要设置生产成本控制的战略目标,如经营层的业务人员(实际上是一些领导们)能按图2的成本控制图谱获取所有部门和所有组件的目标达成数据的话,自然就能及时做出相应的评价、指导和决策调整。关于如何实时采集和展现业务状态数据、以及如何设计战略决策信息舱的详细情况,请参见第八章《商业智能和可视化管理》的内容。

    单车成本构成示意图

    (2)管理层业务组件

    由于管理层处于决策层和执行层之间,从信息沟通的角度来说,具有上情下达、下情上报的职责,一般情况下,上情下达比较容易实现,但下情上达则相对困难,存在诸多的管理和技术问题。管理层业务组件应以提升管理层控制业务过程的能力、以及提高管理层和执行层及战略层之间的信息沟通能力为主线进行设计。管理层作业的重点应按如下思路设置:

    - 对于某个典型业务的企业战略,是否具有明确的计划编制、监督实施等作业标准。

    如部门接受了达成企业某个战略,或实现某个企业年度指标的任务时,应该按照既定的作业标准,进行自身业务能力的分析、指标的分解、作业分工以及过程控制方法的确定等作业,以确保该项战略目标或年度绩效指标能按计划展开,并确保其实施过程能得到有效的监控。

    - 相关的典型业务的过程状态是否能有效掌控。

    这一条可以认为是管理层的主要业务方向之一,如一个中层管理人员对如何监控业务过程缺乏最起码的研究,那就基本可以断言,他肯定是一个缺乏最起码业务过程控制能力的管理人员。

    - 对于某些典型业务或某些关键的作业节点,能否实时、有效地评价员工的执行力。

    管理人员之所以需要掌握员工或团队的执行力,不仅仅有利于达成业务目标的正确预测,更重要的是将有利于管理人员发现团队中意愿不足和能力不足的员工,以便及时加以指导。另外,如能实现员工执行力的数据统计,还将有利于事后的正确评价。

    - 对于部门重点业务以及管理改进目标,能否掌握员工知识贡献度的不同。

    能设置符合这一方向的业务组件,其先决条件是必须已经实现了基本有效的知识管理,否则,这样的要求就偏高了一点。作为一个以创新为主的业务部门的管理人员,必须研究如何做才能达成这样的目的,关于这一点,将在第八章中进行详细的介绍。

    - 对于所承担的企业战略指标部分,是否具有实时采集、分析和上报的机制。

    如果管理层职员基本具备这样的意识,就基本上能够得到他们上司的认可,至少能够保持住当前的官帽。如果能够建立这样的机制,具备这样的能力,那就完全不用担心自己的升迁问题了,因为,能够实现及时、准确地“下情上报”的管理人员,已经充分具备了能随时取悦上司的资本。

       总之,从信息沟通的功能来说,设置中层管理业务组件的目的,一是能够掌握企业战略动态,及时编制、和实施部门业务计划;二是要能够实时掌握执行层业务的作业状态(进度、执行力、作业量、知识贡献等)、并能够及时处理、分析执行层的业务统计数据,以便及时对员工进行指导、督促和评价,以及顺利履行按规定向上通报的职责。根据以上思路设置管理层业务组件,从表面来看,似乎主要关注的是中层管理者们处理信息的能力,但大家必须清醒地认识到这样一个事实,那就是:没有充分有效的反映执行层作业状态的信息,管理层就不可能进行有效的控制、指导和评价,作为管理者的能力,也就不可能得到充分地展现。

    (3)执行层业务组件

        执行层业务组件的设计重点,当然首先要关注组件的设置是否有利于实现所属典型业务的目标,其次是希望它能以最少的资源投入来确保业务目标的实现。如果企业单一系统的建设卓有成效,则基本可以认为该企业的执行层业务组件应该是处于一种良好的状态。但在当前加强目标管理、绩效管理的企业,所有执行层组件应该还要考虑是否需要设置向管理层提供信息服务的功能。归纳起来,应考虑以下要素:

    - 是否能确保实现典型业务的业务目标。

    要回答上述问题,必须对典型业务有完整的认识,所以,必须尽量把有利于实现业务目标的业务活动、操作方法以及技术手段都纳入研讨的范围。也许,在考虑如何才能实现典型业务的业务目标时,暂时可以不要过多地去推敲效率的好坏。

    - 实现业务目标的效率如何。

    如果企业对于作业效率有很高的要求,则在设计业务组件时,或许要更多地考虑组件的合并、组件业务流程的连通方式的改进、执行力的监控等有利于提高作业效率的问题。

    - 业务过程失控的危险是否已完全消除。

    企业中的有些业务,如必须需要通过设置控制基准值,并通过逻辑条件或数学运算规则来发现业务过程失控、指标达成失败等现象时、则需要考虑追加自动监控组件,如果没有自动监控的条件,也应明确人工监控的具体方法。

    - 业务状态数据是否可实时采集、统计和发布。

    对于必须控制进程的业务,则通常需要考虑追加进度监控组件,至少应明确关键节点的进度监控方法。

    - 业务组件之间的协同是否顺畅。

     这一条要求是指业务组件之间的流程连通方式、信息共享方式是否符合业务目标的要求,如果不能达到要求,则要追加某种提升协同能力的辅助组件。

        总之,执行层业务组件是实现典型业务目标的骨干部分,而管理层业务组件的合理设置可确保执行层业务过程得到实时的控制,而战略层业务组件则应起到目标调整、资源调整的决策作用。

    在进行上述三个层面的业务组件设置时,如果已经掌握了相对先进的、行业内的最佳实践模式,并对该典型业务进行过组件构成合理性的分析,或者根据日常的业务不良投诉记录,已经掌握了某些组件的问题,那么,在分析和描述该项典型业务时,可明确地表达出该典型业务在构成上的缺失或冗余项,以及当前这些业务组件的业务能力的总体状态。在分析中,最容易发现的是业务组件的缺失项,即一些目前我们还没有开展的业务,而这些业务的开展恰恰有利于企业最新战略的实现。但发现所谓冗余项,则通常是一个不容易完成的任务,因为,大多数员工不会斗胆挑战现有业务存在的合理性,因为大家已经习惯于把时间打发在这些日常业务上了。但作为业务分析人员,建议大家必须时常保持高度的怀疑态度,因为任何业务组件的存在都要消耗资源,为此,任何业务组件都存在压缩、分解乃至取消的可能,如果能通过业务的重组或优化,凸现出某些业务的冗余功能,并最终取消之。这才是分析人员应该加以重点研讨的方向,才是大家更值得骄傲的地方。真所谓“居人之所恶,故几于道”,我们业务分析人员,没有必要对自己始终保持对现实的批判态度而心怀歉疚,反倒应该随时提醒自己,要始终保持对现有业务合理性的怀疑态度,在这方面,做“恶人”比做“好人”,更能体现业务分析人员的职业价值。对于上述的分析结果,自然应在业务架构图中表达出来,具体的表达方式可参见图2-4。在图中,采用的是用色彩区分来表达组件业务能力状态的方法,虽然这种表达方法比较直观,但肯定不是唯一的表达方法,在此建议大家不必拘泥于形式,只要能容易理解即可。

    和最佳实践模式对标或完成调查和分析后的业务热点分析图

        不过,有一点,希望大家注意,上述的架构图是一张企业级的典型业务架构概略图,所以,对于每一个典型业务,都包含了所有相关部门的业务组件。但实际上,我们的很多具体分析,往往只须针对一个部门的业务展开即可。在这种情况下,也可以按照上述的方法编制部门级业务架构图,只是这种架构图在大多数情况下,不需要考虑战略层的组件设计,所以,只采用两层的架构图也是没有问题的。另外,根据需要,对于部门级的业务,还可以编制一种横向按时间顺序展开的架构图,但这种架构图不利于展开全局性的分析,所以,通常不采用,这里就不作详细说明了。

       根据以上两个图例,读者是否不再介意使用‘业务架构’这样的表达方法了呢?为此可以认为,即使是相对抽象的业务也是可以用相对直观的架构形式来表达的。这样的表达方式不仅仅只是为了直观地进行业务的归纳,更重要的是为了直观地表达出现有业务架构的缺陷。图3中,红色的组件表示缺失、冗余或存在严重缺陷的组件,此类组件我们通常称之为“热点组件”(这样的架构图也可称之为热点组件示意图)。红色组件通常是表示尚未实施改进对策的热点组件。粉红色的组件则表示该组件虽有问题,但目前正在对策中。黄色的组件表示存在当前可以默许的缺陷,但随着企业的发展也许需要加以关注的组件,通常其评价的平均得分低于3分。绿色则表明该模块当前运行正常,暂时不需要特别关注的业务。当面对如此直观明了的业务架构图。没有理由不对缺失的和有缺陷的模块部分进行进一步的问题定位分析、并制定改进方案。但怎样才能知道A组件是缺失,应该考虑增设,或B组件有缺陷,需要改进呢?这便是后面的章节中将要重点介绍的核心内容。

    下面这张就是画的比较细的业务架构图

    ​​​​​

    技术架构

    从技术层面描述,主要是分层模型,例如持久层、数据层、逻辑层、应用层、表现层等,然后每层使用什么技术框架,例如Spring、hibernate、ioc、MVC、成熟的类库、中间件、WebService等,分别说明,要求这些技术能够将整个系统的主要实现概括。

    技术框架(technological Framework)是整个或部分技术系统的可重用设计,表现为一组抽象构件及构件实例间交互的方法;另一种定义认为,技术框架是可被技术开发者定制的应用骨架。前者是从应用方面而后者是从目的方面给出的定义。

    实例图:

    业务流程

    业务流程,是为达到特定的价值目标而由不同的人分别共同完成的一系列活动。活动之间不仅有严格的先后顺序限定,而且活动的内容、方式、责任等也都必须有明确的安排和界定,以使不同活动在不同岗位角色之间进行转手交接成为可能。活动与活动之间在时间和空间上的转移可以有较大的跨度。而狭义的业务流程,则认为它仅仅是与客户价值的满足相联系的一系列活动。

    流程图

    竖式业务流程图就是要业务流从上到下,看起来一目了然。

    竖式业务流程图可以划制成矩阵式流程图,就可以同时说明业务、工作的流程,还可以在流程中明确各自的分工和职责,关键的控制点等。业务流程要重点注意可靠性、资源利用率、反应性、灵活性、较低的管理成本五方面问题。

    综述

    良好的业务流程设计是保证企业灵活运行的关键。清晰的定义业务流程之间的接口,可以降低业务之间的耦合度,使得对局部业务流程的改变不会对全局的流程产生灾难性的后果。

    对整个企业的业务流程进行建模是一个相当复杂而有挑战性的工作,但是并不代表没有方法可循。一般来说,建模需要处理好以下几个方面:

    建立流程

    主要的业务流程是由直接存在于企业的价值链条上的一系列活动及其之间的关系构成的。一般来说包含了采购、生产、销售等活动。 辅助的业务流程是由为主要业务流程提供服务的一系列活动及其之间的关系构成的。一般来说包含了管理、后勤保障、财务等等活动。

    层次关系

    业务流程之间的层次关系反应业务建模由总体到部分、由宏观到微观的逻辑关系。这样一个层次关系也符合人类的思维习惯,有利于企业业务模型的建立。一般来说,我们可以先建立主要业务流程的总体运行过程,然后对其中的每项活动进行细化,建立相对独立的子业务流程以及为其服务的辅助业务流程

    业务流程之间的层次关系一定程度上也反映了企业部门之间的层次关系。为使得所建立的业务流程能够更顺畅的运行,业务流程的改进与企业组织结构的优化是一个相互制约、相互促进的过程。

    合作关系

    企业不同的业务流程之间以及构成总体的业务流程的各个子流程之间往往存在着形式多样的合作关系。一个业务流程可以为其它的一个或多个并行的业务流程服务,也可能以其它的业务流程的执行为前提。可能某个业务流程是必须经过的,也可能在特定条件下是不必经过的。在组织结构上,同级的多个部门往往会构成业务流程上的合作关系。

    展开全文
  • 业务架构 应用架构 数据架构 实战

    千次阅读 2021-10-03 13:08:24
    作者:温昱 出版社:电子工业出版社 品牌:博文视点 出版时间:2021-02-01 业务架构 应用架构 数据架构 实战
  • Microsoft.NET企业级应用架构设计 第二版 扫描版的
  • 文章目录前言 前言 本文整理自华为云社区【内容共创】活动第14期。 查看活动详情:https://bbs.huaweicloud.com/blogs/336904 相关任务详情:任务16.企业核心业务未来架构演进路线及华为云方案
  • 文章目录1 什么是架构图?1.1 架构图的定义1.2 架构图的分类 1 什么是架构图? 1.1 架构图的定义 往往系统是非常复杂的,无法一下子全部表达清楚,架构要涵盖的内容和决策太多了,超过了人脑"一蹴而就"的能力范围...
  • 软件开发就是把一个复杂的问题分解为一系列简单的问题,再把一系列简单的解决方案组合成一个复杂的解决...但架构并非镜花水月或阳春白雪,有系统的地方就需要架构,大到航空飞机,小到一个电商系统里面的一个功能组...
  • 什么是应用架构

    千次阅读 2020-11-18 20:12:44
    应用架构 由于互联网的发展,带动着并发的激增,我们的应用架构也随之进行了升级,这里主要讲几个主要架构类型 1.单体架构 什么是单体架构 单体架构优缺点
  • 分布式web系统架构图及应用架构

    千次阅读 2022-02-08 14:15:16
  • IT项目中的应用架构、技术架构、安全架构、部署架构 在日常软件项目开发与实施中,经常会涉及到各种架构图,如应用架构、技术架构、安全架构、部署架构。今天特意将这些架构图整理如下,提供给大家进行学习参考。 一...
  • 业务架构是跨系统的业务架构蓝图,应用架构,数据架构,技术架构是解决方案的不同方面。 BA(Business Architecture,业务架构) DA(Data Architecture,数据架构) AA(Applications Architecture,应用架构) ...
  • 微服务架构设计实践 目 次1 序言2 微服务3 软件架构设计思想4 微服务架构设计实践4.1 项目概述4.2 架构准备阶段4.3 概念架构阶段4.4 细化架构阶段4.4.1 业务架构4.4.2 数据架构4.4.3 应用架构4.4.4 技术架构4.4.5 ...
  • Java应用架构设计

    千次下载 热门讨论 2014-07-16 16:54:30
    Java应用架构设计:模块化模式与OSGiJava应用架构设计
  • 架构可细分为业务架构、应用架构、技术架构, 业务架构是战略,应用架构是战术,技术架构是装备。 应用架构承上启下: 1、一方面承接业务架构的落地, 2、一方面影响技术选型 应用架构类型:单体式、分布式、SOA...
  • 应用架构COLA3.0:让事情回归简单

    万次阅读 多人点赞 2020-06-26 23:45:46
    最近,阿里云的同学告诉我,COLA作为应用架构,已经被选入阿里云的Java应用初始化的应用架构选项之一。 This is really something,于是,在这个里程碑节点上,我开始回过头来,重新审视COLA一路走来的得与失。 ...
  • 第2章 TOGAF理论全景解读 2.1 解读TOGAF 9.2的BA、DA、AA、TA内容模型 BA 属于现实世界,DA,AA,TA 属于IT世界。前者是后者的起源,后者是...用到的应用 --- 应用系统 7.用到的技术 --- 技术设施 2.2 解读TO.
  • 企业的应用架构演变之路

    千次阅读 2017-05-06 16:08:36
    作者|杨堃编辑|Gary ...良好的、合理的应用架构可以支持企业高效开展业务,控制经营风险,而混乱的、不合理的应用架构则会限制企业的快速发展,成为企业增长与变革的瓶颈。 企业信息化建设已经发展了几十年,传
  • Java应用架构设计、 如何进行模块化模式、与OSGi有什么联系?
  • 什么是数据应用 数据应用是通过各种各样的数据分析方式将数据展示出来,给决策者、管理者、运营等人员透传数据价值的工具,帮助决策者、管理者及时调整战略目标、公司目标、业务目标,帮助运营人员更好地实现...
  • “供应链金融”平台应用架构 为了更加直观的介绍“供应链金融”系统平台应用架构,将苏宁金融的企业贷款平台应用架构作为案例来介绍如图(1.2)。苏宁金融的企业贷款平台的应用架构是基于当下苏宁金融内部特定的...
  • 架构可细分为业务架构、应用架构、技术架构,业务架构是战略,应用架构是战术,技术架构是装备。其中应用架构承上启下,一方面承接业务架构的落地,另一方面影响技术选型。如何针对当前需求,选择合适...
  • 微软应用架构指南(第2版)

    热门讨论 2014-01-17 17:34:28
    软件架构和设计篇  第1章什么是软件架构  第2章软件架构的关键原则  第3章架构模式和风格  第4章架构和设计的方法 设计基础篇  第5章分层应用程序指导原则  第6章表现层指导原则  第7章业务层指导原则  第8...
  • 应用架构演进

    千次阅读 2017-05-23 17:12:58
    1. 传统的垂直应用架构: 就是我们现在企业中最常用的MVC架构,它有一个主要的特点就是技术单一,开发上手快,测试,部署都是比较简单的 MVC的三层结构: a. 最前端的是V(view),主要是用于前端页面展示,使用...
  • 单一应用架构-垂直应用架构-分布式应用架构 单一应用架构的话我理解为普通的传统项目SSH、SSM的 分布式的话就是市面上的将服务分布在不同的服务器上 那么这个垂直应用架构是什么呢/

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 1,582,725
精华内容 633,090
关键字:

应用架构

友情链接: Huang.zip