第一周学习总结

前言

最近机缘巧合关注到了智慧老师的架构训练营课程，稍微考虑下就参加了。其实自己参加工作这么多年来，大大小小的设计文档也写了不少，但是越来越感觉自己对所谓的架构设计缺乏系统的认识，趁这个机会站在智慧老师的肩膀上，开拓下对架构设计的视野。

本文算是自己从智慧老师的课程中领悟到的知识的梳理吧，可能会有点零碎，各位读者多多包涵。

什么是架构？

之前我们讨论架构，都是说“设计xx系统的架构”或者“为xx系统做一个架构”，我们的关注点都在系统本身上。智慧老师的一个观点很新奇：“系统本身就在那里，系统不需要你做架构，是我们人需要你做架构”。这句话就将架构的关注点放在干系人上，我们做这个架构，就要关注这个架构是做给谁看的，这对我来说是一个比较新的思考方向。

智慧老师对架构的定义，印象最深的就是下面这个图了，下面借用一下。



• 架构由架构元素和元素间关系组成，每个系统都有各自的架构。

• 架构元素包括服务器、交换机等基础设施和软件服务、软件模块，甚至与类等。

• 元素间关系包括服务器间通讯、模块调用关系，类之间的关系等。

• 架构的表现形式是架构文档，系统是有相应的相关方的。

• 所以我们做架构、写架构文档，都是为了交付给相关方的。

• 相关方不仅是系统的最终用户，还会包括你的领导和其他团队成员。

• 我们的架构是要得到相关方的认可，相关方能够通过架构文档理解你的架构。

• 架构文档会包含很多的架构视图，而架构视图是描述相关方的不同关注点的。



通过这个图，也更明确为什么说“系统不需要你做架构，是我们人需要你做架构”。因为我们所谓做架构的时候，是将自己脑海的架构表现到文档中，通过不同的架构视图将不同相关方的关注点描述清楚，得到相关方的认可和理解。那么这个架构，或者说架构文档才是有意义的。

例如：不能解决实际业务问题，技术应用再酷炫，也得不到用户的认可；或者说架构设计的很完美，但是不能落地，开发团队成员无法理解，那么架构也没什么意义；

什么是架构师？

智慧老师对架构师的定义是：架构师是一个Title(头衔)，而不是一个职位。只要你做了架构，就是架构师。

我的理解很简单，我们不管做大系统还是小模块的时候，我们都有对应的架构，都有相关方，我们不管通过架构文档也好，代码实现也罢，都有聚焦相关方的关注点，做好我们的架构。那就可以做架构师，当我们熟练的应用这套模式，再加上技术的广度和深度得到提升之后，你就能获得公司认可的那个架构师Title。

如何写架构文档？

架构文档就是将你脑海中对系统的描述，用语言描述出来，就是架构文档。对于如何写架构文档，网络上也有很多的文档模板，我这里不打算详细描述不同的文档该怎么写，我只根据学习中get到的点结合自己的想法，罗列在编写架构文档过程中我们应该关注哪些要点。

• 架构文档需要聚焦相关方，对于不同的相关方，我们可能需要提供不同的架构设计文档。

• 写架构文档前需要先进行建模

• 模型是对某个领域的抽象；

• 设计者将对于该领域的理解都体现在模型中；

• 将模型通过图形化的方式表达出来；

• 统一的建模语言很有必要

• 目前广泛使用的建模语言就是UML，通过图形化方式表达建模思想，统一标准化，减少沟通成本；

• 因为UML是一门语言，所以会有“方言”的概念，所以实际工作中，可以不用过于纠结图形细节。但是相对标准化还是很必要，关键点还是要区分清楚。

• UML图中，常用的有：用例图、....

• 因为架构文档、UML图都是在向相关方展示设计思路。那么文档要简洁、精炼，突出重点，逻辑清晰。

• 如果架构复杂，就将文档分成多份，每份侧重点不同。架构简单的话，就一个文档，分章节描述。

• 一个模型复杂就拆分成多个图去描述，在图中通过简单的短语描述设计意图。也可以为图形配上简短说明。

• 一个图中要逻辑清晰，多个图之间要逻辑连贯。