架构师训练营第一周学习笔记

架构的几个视图

一个系统，会设计到不同角色的人。不同角色关注的点是不一样的。我们不能拿着同一份架构文档给所有人的看，而是要针对的不同的人专门准备一份，从他关注的角度来讲系统的架构。



比如，开发会关心要怎么写代码，运维会关心系统怎么部署，用户会关心系统怎么用，财务可能会关心项目成本是多少……



不同的角色看同一个事物，站的视角不同，看到了同一事物的不同方面，也就是不同的「视图」。就像我们使用 SQL 数据库，可以基于一张或多张表建立视图，可以建立多个视图，不同的视图展示的字段不同。不管我们建了多少个视图，表只有一份。设计架构时，我们的架构只有一份，但可以根据需要，从不同的视角创建视图。



常用的 4+1 视图：

• 逻辑视图：设计的对象模型

• 过程视图：捕捉设计的并发和同步特征

• 物理视图：描述了软件到硬件的映射，反应了部署特性

• 开发视图：描述了在开发环境中软件的静态组织结构

• 场景视图：描述用例场景



逻辑视图

• 相关方：客户、用户、开发组织管理者

• 视角：系统的功能元素，以及它们的接口、职责和交互

• 主要元素：系统、子系统、功能模块、子功能模块、接口

• 用途：开发组织划分，成本、进度的评估

过程视图

• 相关方：性能优化、开发相关人员

• 视角：系统运行时线程和进程的情况

• 主要元素：系统进程、线程以及处理队列等

物理视图

• 相关方：系统集成商、运维人员

• 视角：系统逻辑组件到物理节点的物理部署和节点之间的物理网络配置

• 主要元素：物理节点以及节点的通信

开发视图

• 相关方：开发相关人员、测试人员

• 视角：系统如何开发实现

• 主要元素：描述系统的层、分区、包、框架、系统通用服务、业务通用服务、类和接口、系统平台和相关基础框架

• 用途：指导开发组织设计和开发实现

场景视图

• 相关方：用户、设计和开发人员

• 视角：概括了架构上最重要的场景（最典型或最具风险），及其非功能性需求，通过这些场景的实现，阐明了架构的广度或众多架构元素运行的方式

建模

现实生活中，很多情况都需要建模，比如盖房子。为什么建模？建模是为了验证某件事能够工作。建模的成本远低于实物的成本。



软件建模的价值在于，它可以在软件开发的过程中方便各方沟通，即使在软件开发完成后，这个模型也有利于了解整个软件。



软件建模，推荐使用 UML。



UML 的图有静态图和动态图两类。

• 静态图：

• 用例图

• 对象图

• 类图

• 组件图

• 包图

• 部署图

• 动态图

• 协作图

• 序列图

• 活动图

• 状态图

其中，个人经验，最常用和实用的有：用例图、类图、部署图、组件图、序列图和状态图。



不同的图，适用的时间点不太相同。

• 需求设计阶段：用例图、时序图、活动图、状态图

• 概要设计：类图、时序图、活动图、组件图、部署图

• 详细设计：类图、时序图、活动图、状态图



主要原因是，不同的图涉及的信息的粒度不同，越在早期，粒度越大。比如用例图，只描述系统要提供什么价值、功能等，而不必在在这个时候就确定要开发哪些接口和实现哪些类。