第一周学习总结

用户头像
CP
关注
发布于: 2020 年 06 月 09 日

前言

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

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

什么是架构?

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

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



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

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

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

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

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

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

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

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



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

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

什么是架构师?

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

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

如何写架构文档?

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

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

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

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

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

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

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

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

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

  • UML图中,常用的有:用例图、....

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

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

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

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



用户头像

CP

关注

还未添加个人签名 2018.03.15 加入

还未添加个人简介

评论

发布
暂无评论
第一周学习总结