网站怎么建立会员,濮阳市网站建设公司,住建部2022年执行的新规范,超级优化目录
一、 RUP41 架构
1.1 RUP41架构方法概述
1.2 RUP41架构总体
1.3 RUP41架构方法内容
1.3.1 逻辑视图
1.3.2 开发视图
1.3.3 物理视图 1.3.4 处理视图 1.3.5 场景视图
二、 TOGAF9 架构
2.1 TOGAF9 架构概述
2.2 TOGAF9 架构分类
2.2.1 业务架构
2.2.2 数据架…
目录
一、 RUP41 架构
1.1 RUP41架构方法概述
1.2 RUP41架构总体
1.3 RUP41架构方法内容
1.3.1 逻辑视图
1.3.2 开发视图
1.3.3 物理视图 1.3.4 处理视图 1.3.5 场景视图
二、 TOGAF9 架构
2.1 TOGAF9 架构概述
2.2 TOGAF9 架构分类
2.2.1 业务架构
2.2.2 数据架构
2.2.3 应用架构
2.2.4 技术架构
2.2.5 代码架构
2.2.6 部署拓扑架构图 在 EA 架构领域有两种常见架构方法 RUP 和 TOGAF这两个框架也是我们常常了解架构分类的两个维度。RUP41 架构方法主要是以架构生命周期为视角进行描述而 TOGAF9 按架构涉及内容维度来描述。从我个人的角度觉得 TOGAF 的分类方式更加广泛使用。
一、 RUP41 架构
1.1 RUP41架构方法概述
1995 年Philippe Kruchten 在《IEEE Software》上发表了题为《The 41 View Model of Architecture》的论文引起了业界的极大关注并最终被 RUP 采纳。即 RUP41 架构方法。该方法主要采用用例驱动在软件生命周期的各个阶段对软件进行建模,从不同视角对系统进行解读从而形成统一软件过程架构描述。该方法的不同架构视图承载不同的架构设计决策支持不同的目标和用途。
1.2 RUP41架构总体 1.3 RUP41架构方法内容
1.3.1 逻辑视图
用于描述系统软件功能拆解后的组件关系,组件约束和边界,反映系统整体组成与系统如何构建的过程。关注功能和逻辑层。 1.3.2 开发视图
描述系统的模块划分和组成,以及细化到内部包的组成设计,服务于开发人员,反映系统开发实施过程。 1.3.3 物理视图
描述软件如何映射到硬件反映系统在分布方面的设计系统的组件是如何部署到一组可计算机器节点上,用于指导软件系统的部署实施过程。 1.3.4 处理视图
用于描述系统软件组件之间的通信时序,数据的输入输出,反映系统的功能流程与数据流程,通常由时序图和流程图表示。关注进程、线程、对象等运行时概念以及相关的并发、同步、通信等问题。 1.3.5 场景视图
也称为用例视图Use Cases View关注最终用户需求为整个技术架构的上线文环境.通常用UML用例图和活动图描述。
二、 TOGAF9 架构
2.1 TOGAF9 架构概述
TOGAF 即 The Open Group Architecture Framework 开放组体系结构框架是由致力于技术标准制定和推广的非盈利组织 The Open Group 制定的用于开发企业架构Enterprise Architecture的一套方法和工具。 2.2 TOGAF9 架构分类
业务架构是战略应用架构是战术技术架构是装备。其中应用架构承上启下一方面承接业务架构的落地另一方面影响技术选型。熟悉业务形成业务架构根据业务架构做出相应的应用架构最后技术架构落地实施。在这里我结合RUP41 架构方法和TOGAF9架构方法将架构设计细分为业务架构、应用架构、数据架构、技术架构, 代码架构, 部署架构。其中业务架构、应用架构、数据架构、技术架构为TOGAF9架构方法的架构分类内容。 2.2.1 业务架构
描述定义业务战略、治理、组织和关键流程。
包括业务规划业务模块、业务流程对整个系统的业务进行拆分对领域模型进行设计把现实的业务转化成抽象对象。业务架构是企业治理结构、商业能力与价值流的正式蓝图。业务架构明确定义企业的治理结构、业务能力、业务流程、业务数据。其中业务能力定义企业做什么业务流程定义企业怎么做。业务架构就是对企业的业务流程进行根本性的再思考和在思考的彻底性再设计从而获得成本、质量、速度等方面业绩的巨大的改善或提高。
业务架构包含
1、战略
2、企业业务流程(价值链)当前能力
3、未来能力商业能力IT 能力。
网上微信业务架构图分享 2.2.2 数据架构
描述组织的逻辑与物理数据资产及数据管理资源的结构
数据的三种状态散着叫资源统着叫资产赋能叫资本。
数据架构的价值通过数据架构引领数据资产形成数据资本。
数据架构指导数据库的设计. 不仅仅要考虑开发中涉及到的数据库实体模型也要考虑物理架构中数据存储的设计。 2.2.3 应用架构
描述提供包含待部署的独立应用及其之间交互作用与组织的核心业务流程间的关系蓝图
集成的方法总线/微服务。
传统企业稳态业务用总线。 互联网络敏态业务用微服务。
硬件到应用的抽象包括抽象层和编程接口。应用架构和业务架构是相辅相成的关系。业务架构的每一部分都有应用架构。
应用架构是要说明产品架构分哪些应用系统应用系统间是如何集成的。这就是应用架构和应用集成架构。应用架构在产品架构的基础上考虑两个事情第一、考虑的是子系统间的关系。第二、考虑将可复用的组件或模块进行下沉沉淀到平台层为业务组件提供统一的支撑。
应用架构应用作为独立可部署的单元为系统划分了明确的边界深刻影响系统功能组织、代码开发、部署和运维等各方面. 应用架构定义系统有哪些应用、以及应用之间如何分工和合作。这里所谓应用就是各个逻辑模块或者子系统。
应用架构图关键有 2 点
1、职责划分: 明确应用各个逻辑模块或者子系统边界
1逻辑分层
2子系统、模块定义。
3关键类。
2、职责之间的协作
1接口协议应用对外输出的接口。
2协作关系应用之间的调用关系。
应用分层有两种方式
一种是水平分横向按照功能处理顺序划分应用比如把系统分为 web 前端/中间服务/后台任务这是面向业务深度的划分。
另一种是垂直分纵向按照不同的业务类型划分应用比如进销存系统可以划分为三个独立的应用这是面向业务广度的划分。
应用的合反映应用之间如何协作共同完成复杂的业务 case主要体现在应用之间的通讯机制和数据格式通讯机制可以是同步调用/异步消息/共享 DB 访问等数据格式可以是文本/XML/JSON/二进制等。
应用的分偏向于业务反映业务架构应用的合偏向于技术影响技术架构。分降低了业务复杂度系统更有序合增加了技术复杂度系统更无序。应用架构的本质是通过系统拆分平衡业务和技术复杂性保证系统形散神不散。
系统采用什么样的应用架构受业务复杂性影响包括企业发展阶段和业务特点同时受技术复杂性影响包括 IT 技术发展阶段和内部技术人员水平。业务复杂性包括业务量大必然带来技术复杂性应用架构目标是解决业务复杂性的同时避免技术太复杂确保业务架构落地。
2.2.4 技术架构
描述支持业务、数据和应用服务部署所需的逻辑的软件与硬件能力包括IT基础设施、中间件、网络、通讯、部署处理和一些标准等
未来信息化技术公共平台体系。 以往用技术路线形成标准化的技术环境。 现在用技术平台形成标准化的技术环境。 建平台/定标准/上应用/通数据。
应用架构本身只关心需要哪些应用系统哪些平台来满足业务目标的需求而不会关心在整个构建过程中你需要使用哪些技术。技术架构是应接应用架构的技术需求并根据识别的技术需求进行技术选型把各个关键技术和技术之间的关系描述清楚。
技术架构确定组成应用系统的实际运行组件lvsnginxtomcatphp-fpm 等这些运行组件之间的关系以及部署到硬件的策略。技术架构还要考虑系统的非功能性特征对系统的高可用、高性能、扩展、安全、伸缩性、简洁等做系统级的把握。系统架构的设计要求架构师具备软件和硬件的功能和性能的过硬知识这也是架构设计工作中最为困难的工作。
2.2.5 代码架构
子系统代码架构主要为开发人员提供切实可行的指导如果代码架构设计不足就会造成影响全局的架构设计。比如公司内不同的开发团队使用不同的技术栈或者组件结果公司整体架构设计就会失控。
代码架构主要定义内容
一、代码单元:
1、配置设计
2、框架、类库。
二、代码单元组织
1、编码规范编码的惯例
2、项目模块划分
3、顶层文件结构设计比如 mvc 设计
4、依赖关系 2.2.6 部署拓扑架构图
拓扑架构包括架构部署了几个节点节点之间的关系服务器的高可用网路接口和协议等决定了应用如何运行运行的性能可维护性可扩展性是所有架构的基础。这个图主要是运维工程师主要关注的对象。
物理架构主要考虑硬件选择和拓扑结构软件到硬件的映射软硬件的相互影响。 如果觉得对您有帮助欢迎点赞收藏关注
