写点什么

关于架构的几件小事:架构概述 (1)

用户头像
北风
关注
发布于: 2020 年 07 月 12 日
关于架构的几件小事:架构概述(1)

不同于技术实现的绝对过程(代码换一种形式可能就跑不了...)。架构设计是一个相对论。一切的一切,都建立在目标以及相对可承受的代价上。架构是一种平衡。我这里说的目标,并不只有系统的目标。同样也有相关的利益相关人的目标。对,任何系统的实现,可能都最终会变成该组织的映射。这种相对的关系,在架构概述上有非常显著的体现。同一个架构设计,可能会有很多种架构概述,它们长的都不大一样,但又有统一的目标。所以架构设计令很多架构师着迷,却也令很多人困惑。



概述的概述



架构概述,也叫:Architecture Overview。它是一个架构设计的大纲,也是核心。大多时候,架构概述是架构设计在客户的提案中集中体现。但架构概述并不是整个架构设计的全部,它可能是一个架构设计的开端,可能是一个架构设计的结尾,也可能是中间过程。架构师可以用他觉得合适的方式去画架构概述。同一个架构设计也可能有多种架构概述。但无论何种形式,架构师应该始终清楚架构概述的目标:它是一个大纲。所有人通过这个大纲,来连接在一起,共同实现系统。所以为了能让人更好的理解这个大纲。所以针对不同的背景的人,可以有不同的表达方式。故架构概述因人而异。但架构师需要把握整理,虽然不同的人看到的架构大纲不同,但他们的内在内核是同一个设计。



[以下图片来自互联网,并非同一个项目,仅仅说明不同的视角(Viewpoint) 看到的架构概述可能是不同的]

业务视角的架构概述





技术视角的架构概述





运维视角的架构概述





确定性的决策



其实在架构概述的时候,不管是显示的还是隐式,其实都包含了一个决策的过程。一般称之为架构决策(Architecture decision)。实际上这个过程才是架构设计中最能体现架构师功力的过程。我们说了架构设计千变万化,但内在是同一的。这个同一性,就是架构决策。所以的架构概述里面出现的元素,都要有理有据,有提问,有回答。图上的元素,为什么用这此元素而非彼元素。需要明确的决策。即使元素是开放式的。例如数据库连接形式,那么也需要给出确定性的范围:例如组件通过JDBC连接数据库,连接数量不能多于10个。这个过程比较复杂,咱们这次不关注如何决策,而是关注确定性。经过这个过程之后,架构概述才是一个真正能站得住的架构概述。当架构师站在台前向客户演示的时候,才能扛得住客户暴风骤雨般的提问。实际上架构设计可能不是一个人设计的。这个过程会参与很多人。大家一条一条过,每个细节可能都千锤百炼。所以有经验的架构师一眼就能分辨出来,这个架构概述是copy 别人的,还是自己做出来的。至少架构决策在架构概述上,可以初见端倪。

新的开始

架构设计到此其实并未结束。架构概述之所以称之为概述。主要还是因为架构总是只是一个大纲,一开始并不精确。在整个架构设计过程内,架构概述需要反复迭代锤炼,精益求精。这个过程做完,再往下一步的时候,又会发现新的问题,这时候回来继续锤炼,反复迭代,直到架构是可落地的,严丝合缝的。

发布于: 2020 年 07 月 12 日阅读数: 1405
用户头像

北风

关注

不想当咖啡师的架构师,不是好摄影师 2019.03.26 加入

斜杠中年

评论 (1 条评论)

发布
用户头像
应朋友的建议,将“架构综述”改成了“架构概述”。这样更准确一些。
2020 年 07 月 12 日 15:09
回复
没有更多了
关于架构的几件小事:架构概述(1)