Question

回想你最近一次看到的软件架构图。它看起来像什么，展示了哪个层次的细节，是否包含了技术选择？根据我的经验，大部分架构图都忽略了任何有关技术的信息，而是专注于说明功能分解和主要概念元素。这是为什么？

在设计过程中绘图

绘制软件架构图的主要原因之一是在软件设计过程中交流思想，就像你会在建筑项目前期看到草拟的蓝图。

在我定期举办的训练班上，我会要求各个小组设计一个简单的金融风险系统，这是其中一堂课上完成的一张架构图的照片。除了解决方案，这张图本身在我所见中也相当典型，它展示了一个概念性设计而不是技术细节。

问人们为什么他们的图不展示任何技术决策，得到的反应多种多样：

“[金融风险系统]的解决方案很简单，可以用任何技术构建”；

“我们不想把一种解决方案强加给开发者”；

“这属于实现细节”；

“我们遵循‘最后责任时刻’原则”。

回顾性绘图

如果你是在软件构建完成之后，为了编写文档而回顾性地绘制软件架构图，那就真的没有理由忽略技术决策。然而，其他人不见得同意这种观点，我经常听到如下评论：

“技术决策会把图搞乱”；

“但是每个人都知道我们只使用ASP.NET操作Oracle数据库”。

架构图应该概念化

无论是在软件构建之前、过程中还是之后画图，似乎都有一个普遍的误解，架构图本质上应该概念化。

软件架构名声不好的一个原因是因为闭门造车的架构师绘制非常高层次的图像来描述他们宏伟愿景造成的刻板印象。我相信你也见过这样的例子：有一个标有“企业服务总线”的大框，连接到云端；或者可能展示了功能分解，却明显没有考虑愿景是否能够实现。如果你真的认为软件架构图本质上应该是肤浅和概念化的，那我的建议是雇用不懂技术的人，应该能解决你的问题。

回到真实世界，我喜欢看到脚踏实地的软件架构，技术选择不应该是实现细节。确保技术得到考虑的一个方法就是将技术选择展示在软件架构图中。

明确技术选择

哪怕你在一个所有软件都用一套标准的技术和模式构建的环境中工作，在软件架构图中包括技术选择都可以消除歧义。想象你在设计一个软件系统。你真的不思考到底要如何实现它？你真的是根据概念化的框和功能分解来思考？如果这些问题的答案是“不”，那么为什么不在图上增加这个额外的信息层。这样做为对话提供了一个更好的起点，特别当你有一个可用的技术选择时。强迫人们在他们的软件架构图中包括技术选择往往还能引发更丰富、深入、脚踏实地的交流。一个肤浅和概念化的图往往会造成许多假设，但分解技术使我们不得不问下面这类问题：

“这个组件如何与运行在单独进程中的另一个组件沟通？”

“这个组件如何初始化，职责又是什么？”

“为什么这个进程需要和另一个进程沟通？”

“为什么这个组件要用X技术而不是Y技术实现？”

其他。

至于技术决策把图搞乱的问题，有多种处理策略，包括使用容器图来单独展示主要技术决策。

在交流大局的整体而不只是其中一部分时，技术选择有助于把其他理想化和概念化的软件设计带回现实，再次脚踏实地。当然，把技术选择加入图中的其他副作用，特别是在软件设计过程中，就是它有助于确保让合适的人来画图。