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



概述的概述



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



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

业务视角的架构概述





技术视角的架构概述





运维视角的架构概述





确定性的决策



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

新的开始

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