Categories
程式開發

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


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

综述的综述

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

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

业务视角的架构综述

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

技术视角的架构综述

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

运维视角的架构综述

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

确定性的决策

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

新的开始

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