[架构师训练营第 1 期] 第一周学习总结

什么叫“整体的架构设计”？可交付的“架构设计”文档包括哪些内容？



如何判断一个系统的技术难点，是业务很复杂、还是并发量很多、亦或是数据很大？技术关键点在哪里、核心组件有哪些（是复杂业务模块，还是高并发或大数据的处理模块）？如何解决这些技术难点（高并发如何解决、复杂的业务服务怎么做、服务之间的依赖关系如何设计）？



如何评价一个系统的性能？什么叫“系统的性能好”？如何提高？关注的技术点在哪里？提高后如何评价？优化后如何评估（系统优化后如何证明自己）？做新的优化的思路和点子是什么（怎么去判断）？如何保证系统的稳定性、高可用（系统故障甚至网络故障时依然能够稳定运行）？



如何确保业务的扩展性？需求和功能增加时怎么扩展？功能模块如何划分？增加新业务时能不能快速开发出来？



以上是本周跟着李智慧老师解读大厂JD（Job Design）整理出来的一些关于架构设计要考虑的问题。



除此之外，架构师还要具备与相关人员进行良好的沟通、组织和协调的技能。相关人员包括：相关合作单位的架构师、老板、相关业务部门或产品部门的产品经理、运营人员等。他们要对架构师的工作进行评审，确定这个架构是满足公司业务需求和满足未来发展的。在未来的开发过程中、合作过程中，各方会有自己的利益诉求，当各自的利益冲突时，一个优秀的架构师应该如何进行调和？



通过解读，在成为架构师这一领域内，我们算是进入了“知道自己不知道”的境界了。



接下来是学习架构设计的基本功，也就是 UML 图。

在学习之前，我们先了解了“4+1视图”理论，即：一个完整的软件架构应具备4+1个视图。

4+1视图包括：逻辑视图、过程视图、物理视图、开发视图，以及场景视图。

这些图构成的模型，其意义在于整合领域问题的解决方案，以指导软件开发，实现对领域问题的解决。

“4+1视图模型”的一个具体实现就是 UML 图。它如今已是软件架构设计的一个事实上标准。

UML 图包括静态图（用例部署类，组件对象包）和动态图（状态时序，活动协作）。

需知，UML 作为一门图形语言，旨在传达架构师意图，规范与否位于其次。



通过对 UML 图画法的简要解读，我们就可以进入实战了，也就是本周的命题作业。



本周，老师还分享了一些他个人作为架构师的有趣经历。

给我的启发是，要想提高自己的水平，就要主动去承担重要的工作，主动接触一流的人员。