目录
[一、 RUP4+1 架构](#一、 RUP4+1 架构)
[1.1 RUP4+1架构方法概述](#1.1 RUP4+1架构方法概述)
[1.2 RUP4+1架构总体](#1.2 RUP4+1架构总体)
[1.3 RUP4+1架构方法内容](#1.3 RUP4+1架构方法内容)
[1.3.1 逻辑视图](#1.3.1 逻辑视图)
[1.3.2 开发视图](#1.3.2 开发视图)
[1.3.3 物理视图](#1.3.3 物理视图)
[1.3.4 处理视图](#1.3.4 处理视图)
[1.3.5 场景视图](#1.3.5 场景视图)
[二、 TOGAF9 架构](#二、 TOGAF9 架构)
[2.1 TOGAF9 架构概述](#2.1 TOGAF9 架构概述)
[2.2 TOGAF9 架构分类](#2.2 TOGAF9 架构分类)
[2.2.1 业务架构](#2.2.1 业务架构)
[2.2.2 数据架构](#2.2.2 数据架构)
[2.2.3 应用架构](#2.2.3 应用架构)
[2.2.4 技术架构](#2.2.4 技术架构)
[2.2.5 代码架构](#2.2.5 代码架构)
[2.2.6 部署拓扑架构图](#2.2.6 部署拓扑架构图)
在 EA 架构领域，有两种常见架构方法 RUP 和 TOGAF，这两个框架也是我们常常了解架构分类的两个维度。RUP4+1 架构方法主要是以架构生命周期为视角 进行描述，而 TOGAF9 按架构涉及内容维度来描述。从我个人的角度觉得 TOGAF 的分类方式更加广泛使用。
一、 RUP4+1 架构
1.1 RUP4+1架构方法概述
1995 年，Philippe Kruchten 在《IEEE Software》上发表了题为《The 4+1 View Model of Architecture》的论文，引起了业界的极大关注，并最终被 RUP 采纳。即 RUP4+1 架构方法。该方法主要采用用例驱动，在软件生命周期的各个阶段对软件进行建模,从不同视角对系统进行解读，从而形成统一软件过程架构描述。该方法的不同架构视图承载不同的架构设计决策，支持不同的目标和用途。
1.2 RUP4+1架构总体
1.3 RUP4+1架构方法内容
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 架构分类
业务架构是战略，应用架构是战术，技术架构是装备。其中应用架构承上启下，一方面承接业务架构的落地，另一方面影响技术选型。熟悉业务，形成业务架构，根据业务架构，做出相应的应用架构，最后技术架构落地实施。在这里，我结合RUP4+1 架构方法和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基础设施、中间件、网络、通讯、部署处理和一些标准等
未来信息化技术公共平台体系。
以往用技术路线形成标准化的技术环境。
现在用技术平台形成标准化的技术环境。
建平台/定标准/上应用/通数据。
应用架构本身只关心需要哪些应用系统，哪些平台来满足业务目标的需求，而不会关心在整个构建过程中你需要使用哪些技术。技术架构是应接应用架构的技术需求，并根据识别的技术需求，进行技术选型，把各个关键技术和技术之间的关系描述清楚。
技术架构：确定组成应用系统的实际运行组件（lvs，nginx，tomcat，php-fpm 等），这些运行组件之间的关系，以及部署到硬件的策略。技术架构还要考虑系统的非功能性特征，对系统的高可用、高性能、扩展、安全、伸缩性、简洁等做系统级的把握。系统架构的设计要求架构师具备软件和硬件的功能和性能的过硬知识，这也是架构设计工作中最为困难的工作。
2.2.5 代码架构
子系统代码架构主要为开发人员提供切实可行的指导，如果代码架构设计不足，就会造成影响全局的架构设计。比如公司内不同的开发团队使用不同的技术栈或者组件，结果公司整体架构设计就会失控。
代码架构主要定义内容：
一、代码单元:
1、配置设计
2、框架、类库。
二、代码单元组织：
1、编码规范，编码的惯例
2、项目模块划分
3、顶层文件结构设计，比如 mvc 设计
4、依赖关系
2.2.6 部署拓扑架构图
拓扑架构，包括架构部署了几个节点，节点之间的关系，服务器的高可用，网路接口和协议等，决定了应用如何运行，运行的性能，可维护性，可扩展性，是所有架构的基础。这个图主要是运维工程师主要关注的对象。
物理架构主要考虑硬件选择和拓扑结构，软件到硬件的映射，软硬件的相互影响。
如果觉得对您有帮助，欢迎点赞+收藏+关注！