架构视图
架构视图是对某一视角或某一点上看到的系统所作的简化描述，描述中涵盖系统某一特定方面，而省略了与此方面无关的实体。
常见的有4+1视图
4+1视图
多视图间信息流动，支撑视图间的一致性
- Logical View 面向系统逻辑分析与设计，描述系统逻辑结构的视图
- Development View 面向系统开发以及软件管理，描述系统代码机构，构建结构的视图
- Deployment View 面向系统部署，描述系统交付，安装，部署的视图
- Process View 面向系统运行，描述系统启动过程，运行期交互的视图
- UserCase View 以用例作为驱动元素，驱动和验证其他四个视图的设计。用例视图不增加设计元素，仅增加用例作为输入，因此是+1视图。
视图与质量属性的关系
质量属性贯穿各视图的另一个维度，直接决定各个视图中的元素和关系设计
用例视图
用例视图描述系统和外部环境之间的关系和交互，并显式定义系统范围，职责，边界以关键用例交互。
目的
- 理解目标系统所处的上下文语境的结构、业务及其动态特性
- 描述系统上下文，确定系统和外部的边界以及外部实体的关系
- 描述关键场景和用例，驱动和验证其他4个视图的设计
建模方法
- 模型：系统上下文模型，系统交互场景模型
- 元素：系统，外部实体（其他系统或人）
- 关系：外部接口，外部依赖关系
系统上下文模型
要点：
- 系统本身及外部实体均为黑盒，隐藏内部结构
- 关注系统及外部实体的职责（服务与数据），质量属性
- 标识系统与外部实体间的接口，职责（提供或使用数据，服务，事件等），质量属性，依赖关系等
- 建议画出组织边界
- 上下文模型中需要完整描述系统对外的接口。包括物理哦接口，逻辑给口，协议栈等。可基于此开展完整的暴露面分析和针对暴露面的威胁分析。
系统用例交互场景
要点：
- 通过系统关键用例界定系统边界和行为
- 对于系统与外部实体之间的关键用例和复杂交互关系，可以采用序列图对交互场景进行建模，一边描述隐含的需求和约束，帮助系统验证
逻辑视图
逻辑视图用于面向设计人员描述系统分解及技术方案
- 逻辑视图描述系统的逻辑分解，以及分解出的逻辑元素间的关系
- 逻辑模型划分的服务，组件等元素是后续其他视图的基准，必须与后续各视图的相应元素如开发视图中的实际代码仓，目录，以及编译构建工程，部署视图的交付单元，可部署单元等建立对应关系
- 可基于逻辑视图开展威胁分析
- 在逻辑视图部件划分时，通常会有用于描述业务功能的业务组件，以及作为技术支撑的技术部件（如database，Cache，中间件），对于这两种部件应采用不同的模型表述，以便支持业务与技术的解耦以及技术部件的替换
- 通过逻辑模型和数据模型描述业务功能，其中不包括技术元素，以及各部件的具体实现技术方案。逻辑模型和数据模型在本领域内重用
- 通过技术模型描述具体的技术方案和技术选型，包括支撑性的技术元素
逻辑视图的基本元素
- 逻辑视图可分层分级表达，如先分成子系统/层/面或者域/子域等，再继续划分
- 系统划分的最小功能元素，根据不同产品采用的技术不同
- 对于云化/微服务架构产品，建议可最终划分到服务/微服务，对于微服务内的组件/模块划分，是否再架构设计中呈现，可由团队自行决定
- 对于组件化/模块化架构的产品，建议最终划分到组件，对于开源/第三方组件，可考虑跟踪到模块。
最细粒度要能跟代码对应上。
逻辑模型 — 系统分解
- 系统功能分解（为什么要分解？）
- 理解业务
- 团队划分
- 高内聚，低耦合
- 逻辑 vs 技术实现
- 逻辑模型与实现技术无关
逻辑模型 — 需求出发，按功能直接分解？
- 流程图分解
- 按照特性、功能进行初步分解
- 按useCase的逻辑步骤分解成服务（或者软件模块）
如何按照功能分解的方式设计一辆车
上面这样按照功能分解时不合适的，车的不同的部件组合实现了上面的功能，比如说上面的左转和前进模块有很多的内部实现是相同的，如果按照这样的分解，是存在极大的冗余的，且同一功能需要多出修改，是不合适的。
因此需要对系统的功能进行抽象，聚类，将系统功能转化为设计部件。
因此架构设计从更关注系统行为转换为更关注系统构成。
数据模型
- 数据模型描述系统存储，操作，管理和分发数据的方式，包括数据结构，内容，所有权，标识符和映射关系等多方面数据相关的设计决策
- 主要描述数据的逻辑结构（数据静态和动态结构，所有权，生命周期等）
- 数据模型中的常见图包括：静态数据结构，动态数据流，数据所有权，数据生命周期
数据模型不直接讲数据库，而是数据结构
技术模型 — 架构实现
- 描述用以支撑系统实现的技术部件，包括框架，中间件等以及实现各功能和质量属性的关键机制，技术方案，编程语言等。
- 描述各功能部件的实现方案和框架代码
- 在某些场景下，实际上转变成了技术“上下文”
技术模型 2D -> 3D -> 4D- 2D：基本的数据结构和实现方案，如MVC，通过ORM连接数据库等
- 3D：各技术部件的技术选型，如ORM选用Hibernate，view选用AngularJS等
- 4D：各技术部件版本选择及演进，如ORM从Hibernate4.3.8演进到4.4.1
在技术模型中需要对4D信息进行描述，既关键技术方案，具体选型，以及版本演进。
逻辑视图推荐方法 —- DDD
聚焦业务领域，以业务模型而非技术实现作为架构设计的驱动力，从而实现业务逻辑上的松耦合。
DDD战略设计：通过衔接是上下文进行系统划分
开发视图
面向开发人员，主要包括开发，测试，编译，构建，维护
设计与代码一致性映射问题
架构设计元素（子系统，服务，组件）与代码元素（代码仓，目录，包，文件）以及构建元素（二进制交付件）之间的对应关系代码，构建依赖问题
架构设计中的依赖关系如何体现在代码中
代码模型
逻辑视图到代码模型的元素映射
- 针对逻辑视图中每个元素，需要给出明确代码仓/目录（微服务，组件独立代码仓（推荐））
- 针对每个元素，需给出内含的目录结构，至少包括内外部接口目录和源文件目录划分
代码模型中的依赖关系的建立
- 在明确代码与逻辑元素映射后，可获取相应元素间的依赖和调用关系模型，形成真实代码依赖和调用关系模型，从而确保代码与架构一致性（有工具可以自动生成）
- 架构和代码间的一致性是双方的。即支持逻辑视图到开发视图到代码的正向一致性；也需支持从代码反向生成开发视图，及与逻辑视图反向同步。
构建模型
从源码到机器码
构建模型主要描述
- 产品构建过程，即从源码到二进制交付件的生成关系
- 每个构建过程中依赖的工具链，以及工具版本信息
- 二进制交付件在运行目录的位置
- 二进制交付件与逻辑视图元素的映射关系
部署视图
用于描述二进制交付件的打包发布及部署
部署视图描述产品交付过程，交付依赖；在测试和生产环境中的功能分布结构，部署对象之间的相互依赖关系等。部署视图显示定义系统的交付编排过程，部署结构及部署的工具
目的
- 确定系统的交付件构成
- 理解目标系统在测试，运行环境的最终形态，其结构组成，部件的依赖关系，呈现整体模型。
- 确定系统的部署工具及部署方法
交付模型
二进制交付件的打包交付过程
交付模型实现从开发视角（二进制交付件）到交付视角（面向客户的订单）的转换
交付模型主要描述
- 产品打包交付过程
- 交付模型中需要明确每个订单包含的内容和整个打包过程
- 打包过程依赖的工具链，以及工具版本信息
- 产品订单与逻辑视图中相应元素的映射关系
运行视图
用于系统运行设计
运行视图主要对进程，进程组，线程，进程间通信等进行建模，也可以对互斥，信号量等保护数据和资源的机制进行建模。同时运行视图还包括架构强关联的功能和特性的运行设计。
运行模型主要包括以下部分
- 逻辑，任务映射：讲逻辑元素映射运行时的执行实体上（暴扣VM，进程，进程组，线程等）
- 运行期的并行处理：包括进程，线程设计，资源共享机制，进程间通讯机制，死锁分析，进程、线程优先级设计。
- 关键运行设计：关键功能，安全/可靠性机制等，可采用顺序图，活动图，状态图等方式