架构师训练营 week1 学习总结

架构师认知

什么是架构师？

架构师是做架构设计、对系统架构负责的那个人。

架构师是一顶帽子，而不是一把椅子；架构师是一个角色而不是一个职位。



架构师的价值

软件技术的进步使得程序员不需要了解技术细节和原理就能开发出能用的软件。

让程序员关注更少的事情有助于提高软件开发效率和质量。



架构师的工作职责

• 编写架构设计文档

• 开发编程框架

• 重构软件代码

• 设计系统架构

• 进行技术选型，解决技术应用中的问题

• 优化系统性能

• 模块分解与微服务架构重构

• 保障系统安全与高可用

• 大数据应用

• 技术创新

• 沟通管理



架构师需要的能力

• 编程能力

• 基础技术掌握能力

• 常用技术产品的理解与应用能力

• 性能优化与分析故障的能力

• 常用架构模式和框架的理解与应用能力

• 建模以及设计文档的方法和能力

• 业务理解与功能模块及非功能模块拆解能力

• 快速学习能力

• 沟通与领导能力



大家关心的一些问题

• 架构师与全栈工程师的区别是什么？两者之间是否有联系？

      - 全栈工程师的核心是所有代码都自己写，关注知识的深度，架构师的职责是让工程师写好代码，更关注知识的广度；他们都是技术高手。

• 架构师应该怎么成长？哪些人适合做架构师？

      - 主动站出来解决问题。

• 技术的广度和深度怎么去选择和平衡？

      - 先对某方面建立深度，做扎实，技术互通，广度依赖于深度，换一个领域很快就能抓住关键点突破。

• 面对一个陌生领域，或者复杂问题时，这种情况就好比您的工作经验比较少的领域，如何突破自我，做到驾轻就熟的？

• 有没有什么好的方式沉淀领域（行业）知识，以便构建个人中台？



如何通过训练提高自己

• 架构方法、架构模式、关键知识点可以训练，但是架构一定要实践，一定要关注场景

• 通过学习例子训练架构思维，总结模式，通过模式，构建知识体系



只有代码是不够的，优秀的架构师必须是软件开发的全才

• 卓越的编程和设计能力

• 解决棘手问题的能力

• 广阔的知识面

• 洞悉技术背后的本质和规律

• 沟通和打动人心的能力



奠定架构师职场地位的要点

• 关于软件开发高超的审美品味

• 关于软件开发技术历史与未来深刻的认知

• 完整的软件技术知识体系

• 带领团队不断获得成功的经历

• 非你莫属、非你不可的影响力

如何奠定架构师职场地位

• 夸夸其谈能帮你带来掌声

• 解决棘手问题能帮你带来名声

• 让别人依赖你写的代码，能帮你赢得地位

4+1视图模型

4+1视图模型：软件开发的本质

软件架构，是有关软件整体结构与组件的抽象描述，用于指导大型软件系统各个方面的设计。- 维基百科

8个元素：核心是架构，架构由元素和关系组成，架构文档由不同的架构视图组成，不同的相关方，关注的点不一样；



4+1 架构视图

软件架构 ＝ {元素，形式，关系/约束}

单一的视图无法完整的表达架构，因此需要具备完整的视图集

• 逻辑视图（Logical View），设计的对象模型

• 过程视图（Process View），捕捉设计的并发和同步特征。

• 物理视图（Physical View），描述了软件到硬件的映射，反映了部署特性。

• 开发视图（Development View），描述了在开发环境中软件的静态组织结构。

• 场景视图(scenarios)，描述用例场景

逻辑视图

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

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

主要元素：系统，子系统，功能模块，子功能模块，接口。

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

开发视图

相关者：开发相关人员，测试人员

视角：系统如何开发实现

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

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

物理视图

相关者：系统集成商，系统运维人员。

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

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

过程视图

相关者：性能优化，开发相关人员。

视角：系统运行时线程，进程的情况。

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

场景视图

相关者：用户，设计和开发人员。

视角：概括了架构上最重要的场景（最典型或者最有风险）及其非功能性需求，通过这

些场景的实现，阐明了架构的广度或众多架构元素运行的方式。

UML建模

什么是模型？

• 模型是一个系统的完整的抽象。人们对某个领域特定问题的求解及解决方案，对它们的理解和认识都蕴涵在模型中。

• 通常，开发一个计算机系统是为了解决某个领域特定问题，问题的求解过程，就是从领域问题到计算机系统的映射。



为什么要建造模型？

基本驱动力就是：编程语言的抽象级别不够高，不便于讨论设计。



何时画图？

• 讨论、交流时

• 最终设计文档

Ø 只保留少量的、重要的图

Ø 避免涉及过多内容和实现细节

何处画图？

• 白板

• 绘图工具，如：Visio、Astah

• draw.io



什么是 UML？

• Unified Modeling Language，或统一建模语言

• 以图形方式描述软件的概念

UML 可用来描述：

• 某个问题领域

• 构思中的软件设计

• 描述已经完成的软件实现



通用模型元素

可以在图中使用的概念统称为模型元素。模型元素在图中用其相应的视图元素（符号）表示，下图给出了常用的元素符号：类、对象、结点、包和组件等。

模型元素与模型元素之间的连接关系也是模型元素，常见的关系有关联（association）、泛化（generalization）、依赖（dependency）和聚合（aggregation）。这些关系的图示符号如图所示。

关联：连接（connect）模型元素及链接（link）实例。

依赖：表示一个元素以某种方式依赖于另一种元素。

泛化：表示一般与特殊的关系，即“一般”元素是“特殊”关系的泛化。

聚合：表示整体与部分的关系。



区别：

依赖与关联：关联关系更紧密，比如类的成员变量是关联，依赖相对较松散，成员方法内的局部变量依赖的另一个对象是依赖关系；

继承与实现：继承父类，实现接口；

聚合与组合：当聚合起来的对象消失的时候，聚合的成员变量还存在，如车和车轮的关系，组合关系更强一些，当组合起来的对象不存在时，组合的成员对象也不存在了，如人和手的关系；



UML2.0的13种图

静态视图（结构图）：对象图、类图、复合结构图、包图、组件图、部署图

动态视图（行为图）：用例图、活动图、状态图、交互图（时序/序列/顺序图、通信/协作/合作图、时间图、交互概览图）



静态建模

任何建模语言都以静态建模机制为基础,标准建模语言UML也不例外。所谓静态建模是指对象之间通过属性互相联系，而这些关系不随时间而转移。

类和对象的建模，是 UML 建模的基础。UML 的静态建模机制包括：

• 用例图(Use case diagram)

• 类图(Class diagram)

• 对象图(Object diagram )

• 包图(Package diagram)

• 组件图(Component diagram)

• 部署图(Deployment diagram)



动态建模

动态模型主要描述系统的动态行为和控制结构。动态行为包括系统中对象生存期内可能的状态以及事件发生时状态的转移，对象之间动态合作关系，显示对象之间的交互过程以及交互顺序，同时描述了为满足用例要求所进行的活动以及活动间的约束关系。

在动态模型中,对象间的交互是通过对象间消息的传递来完成的。对象通过相互间的通信（消息传递）进行合作，并在其生命周期中根据通信的结果不断改变自身的状态。

动态模型主要描述系统的动态行为和控制结构。

包括四类图：状态图、活动图、时序图、合作图。

• 状态图（state diagram）：状态图用来描述对象，子系统，系统的生命周期。

• 活动图（activity diagram）：着重描述操作实现中完成的工作以及用例实例或对象中的活动，活动图是状态图的一个变种。(可用来描述处理流程)

• 时序图（sequence diagram)）：是一种交互图，主要描述对象之间的动态合作关系以及合作过程中的行为次序，常用来描述一个用例的行为。

• 合作图（collaboration diagram）：用于描述相互合作的对象间的交互关系，它描述的交互关系是对象间的消息连接关系。（可以由时序图转换而来，是没有时序信息的时序图）



其中常用7种图：用例图、时序图、活动图、状态图、组件图、部署图、类图