Question

过去的几年中，我发现很多软件开发团队都努力地对他们所构建系统的软件架构进行可视化和交流。我认为主要有三个原因。

1.在很多软件团队加快采用敏捷方法的过程中，都把精华和糟粕一起泼掉了：建模和文档随着传统的计划驱动的过程和方法论一起被扔掉了。

2.看不到文档和图表的价值的团队，往往也抛弃了统一建模语言（UML，当然，假设他们一开始也在用），转而使用更轻量和务实的方法。基于与上千名软件开发者的会议和交谈，我掌握的证据显示，多达九成的软件开发者都不使用UML。

3.很少有人教软件团队如何有效地可视化、建模和交流软件架构。并且，从我为一些计算机科学的学生举办的培训班来看，大学也是如此。

如果在大多数软件开发团队的办公室里晃悠足够长的时间，你一定能找到一些草图，不是画在白板上，就是办公桌上的废纸上。草图是捕捉和呈现软件架构的好方法，但它们通常缺少UML图的正规和严谨。这未必是一件坏事，但图表确实需要能被理解，这也是事情开始变得棘手的地方。过去几年我为上千人举办过软件架构草图专题研讨会，可以毫无疑问地说大多数人都觉得这件事很难。下面选出了一小部分来自这些专题研讨的照片，各组人尝试交流他们对金融风险系统案例的软件解决方案。挨个看看，问问你自己，他们是不是在以有效的方式交流解决方案的软件架构。有些图表使用了颜色，如果你在黑白的电子书阅读器上阅读本书，我向你表示歉意。

采购清单

无论这张图是软件架构图还是一套软件架构图中的一张，都没有太多解决方案的内容，基本上只是一个技术采购清单。

它有一个UNIX框和一个Windows框，还有一些附加的产品选择，包括JBoss（一个Java EE应用程序服务器）和微软SQL服务器。问题在于，我不知道那些产品做了些什么，UNIX框和Windows框之间似乎也缺少某种联系。既然职责和交互没有显示出来，这个图可能更适合用符号列表来展示。

只有框没有线

当人们谈论软件架构，他们往往指的是“框线图”。下面这个图只有框，却没有线。

这是一个采用微软技术栈的三层解决方案（在我看来）。顶部是一个ASP.NET的Web层，我认为它被用于某种用户交互，尽管图中没有明示。底部标有“SQL服务器”，有很多独立的“数据库罐”。老实说，我不知道这些是不是独立的数据库服务器、结构或表。

最后，中间是一些框的集合，我觉得像是组件、服务、模块等。从另一个角度来看，能看到整个解决方案的中间层如何分解成更小块，非常好，这肯定是我在解决方案中希望看到的。但是，还是没有职责和交互。软件架构是关于结构的，是事物（框）以及它们如何相互作用（线）。这图有一点是其他图不具备的，它讲述了一个故事，尽管还不完整。

“功能视图”

这个图跟上一个很相似，也很常见，由于某些原因，在大型组织中尤其常见。

基本上，做出这张图的这个组也把他们对解决方案进行功能分解的过程做了简单的文档，我同样假设是组件、服务、模块等。它也面临着和前一张图相同的问题（没有职责和交互），除此之外我们还要破解颜色编码。你能说出来这些颜色各自代表的意义吗？它是不是跟输入和输出服务有关？或者也可能是业务和基础设施？已有和新增？购买和构建？或者可能只是每个人手里的笔颜色不一样！天知道！经常有人问我为什么中间的“风险评估处理器”的边框明显比其他的粗？我真的不知道，但我怀疑原因只是马克笔的角度不太一样。

航线图

这是我最喜欢的图之一，也是该小组用来展示他们解决方案的唯一一张图。

这张图的中轴线很不错，因为它展示了数据如何从源数据系统（TDS和RDS）进入，然后经过一系列步骤导入数据，执行计算，生成报表，并最终分发。这是一个超级简单的活动图，对于系统在做什么提供了一个很好的高层次概览。但接下来一切就都不对劲了。

我认为图右侧的绿圈很重要，因为一切都指向它，但我不知道原因。还有一个时钟，我感觉这意味着有事情会在某个特定的时候发生。只能祈祷它不是定时炸弹吧！

图的左侧同样令人困惑，各种不同颜色和样式相互纠缠。如果你仔细看，就会发现字母“UI”是倒过来的。说不定把这张图像折纸游戏那样叠起来，会更有意义？

一般正确

这是另一种样式很常见的图。下次再有人要你做一个系统的软件架构图，把这张图给他们就完事了！

这是一个很有“软件架构入门”风格的图，其中大部分内容都是通用的。不看图顶部的源数据系统（TDS和RDS），我们有笼统地标着运输、归档、审计、报表生成、错误处理的框，标着错误和动作的箭头。哦，看看中间的框——还标着“业务逻辑”。你构建过实现“业务逻辑”的软件吗？

有很多方法可以让这张图变得更有效，但只要把“业务逻辑”替换成“金融风险计算器”就至少点出了我们操作的业务领域。在Screaming Architecture1一文中，鲍勃·马丁大叔说，代码组织应该强调跟业务领域相关的东西。软件架构图也应如此。

1http://blog.8thlight.com/uncle-bob/2011/09/30/Screaming-Architecture.html

推迟技术

这张图也比较常见。它展示了软件架构的整体形态（包括职责，这一点我很喜欢），但把技术选择留给了你的想象力。

本书的其他部分会更详细地讨论包含或遗漏技术选择的问题，但基本上有一个误解：“软件架构”图本质上应该是概念化的，不应该包含技术选择。毕竟，我经常听别人说金融风险系统“是一个简单的解决方案，可以用任何技术构建”。

部署和执行上下文

接下来是由一个Web应用程序和一堆服务端组件构成的Java解决方案。尽管它为这一方案提供了一个简单的高层次概览，还是缺少了一些信息，你要靠经验猜出这些空白。

如果你看看图中心的Unix框，就会看到两个更小的，标有“风险分析系统”和“数据导入服务”的框。仔细点，还会看到这两个框上注明了“JAR”，这是Java代码的部署机制（Java ARchive，Java档案）。基本上这是一个包含编译后的Java字节码的压缩文件，相当于.NET的DLL文件。

这里存在歧义。如果你把一个JAR文件放在Unix框里会发生什么？答案是除了占用一些磁盘空间，什么也没有。cron（Unix调度器）不会执行JAR文件，除非它们真的是独立的控制台应用程序，那种以“public static void main”方法作为程序入口的。然后通过推导，我认为这两个JAR文件实际上都是独立的应用程序，这也是我希望在图上看到的。我想了解执行上下文，而不是部署机制。

太多假设

下面的图告诉我们解决方案是一个多层Java EE系统，但它忽略了一些重要的细节。

对于通信是如何发生的，Web服务器和应用程序服务器之间的连线没有提供任何信息。是SOAP、RESTful服务、HTTP请求的XML、远程方法调用、Windows通信基础、还是异步消息？答案是不清楚，我考虑这一点有三个理由。

1.约束：如果是在一个存在约束的环境中工作，技术的选择可能已经为你做好了。比如，你可能有进程间通信的标准，或者只允许某些类型的流量通过的防火墙。

2.非功能需求：技术和协议的选择可能会影响到你能否满足非功能需求，特别是如果你正在处理高性能、可伸缩性和安全性。

3.复杂度：我曾经与从未创建过多层架构的软件团队一起工作，他们往往误以为这种架构风格可以“不费吹灰之力”得来。在现实世界中，更多分层意味着更高的复杂度。

就算有很多选项，团队往往也不喜欢在把一些原型组成整体之前就匆匆提交。没问题，只是换成用潜在选项清单来注释图上那些线，这样至少我们能更好的对话。

无家可归的C#对象（HOCO）

如果你听说过“简单的C#对象”（POCO，Plain Old C# Objects）或“简单的Java对象”（POJO，Plain Old Java Objects），这就是无家可归的版本。这张图混合了许多不同层次的细节。

图的左下部是一个SQL服务器数据库，左上部是一个标为“应用程序”的框。注意，那个框同时还（用绿色）注明了“控制台-C#”。基本上，这个系统似乎是由一个C#控制台应用程序和一个数据库构成的。但其他的框是什么？

它们中大多数似乎是C#组件、服务、模块或对象，跟我们在其他图里已经看过的很像。还有一个“数据访问”框和“记录器”框，可能是框架或架构层。所有这些框是否都代表了跟控制台应用程序和数据库相同级别的粒度，或者它们实际上是应用程序的一部分？我猜是后者，但缺少边界让这张图令人困惑。我想在大多数框周围再画一个大框，“所有这些东西都属于控制台应用程序”。我想给那些框一个家。我想要理解系统如何被分解成更小的组件，同时还想了解执行上下文。

选择你自己的冒险

这是一张图的中间部分，全图更复杂。

这有点像我在孩童时代读过的那些“选择你自己的冒险”的书。你可以从第1页开始阅读，并最终到达一个故事的分叉点，自己决定接下来要怎么做。如果想攻击一个遇到的大怪兽，翻到47页。如果想像懦夫一样逃跑，那就到205页。要一直做类似的选择，最后，如果你的角色死了，就必须重新开始，很讨厌。

这张图也是如此。从顶部开始，一步步向下，这是一个复杂的异步事件驱动的架构风格。你常常要做出选择：应该顺着“失败事件”还是“完成事件”。在这本书里，所有的路径最终都会走向图左侧的（SNMP2）陷阱。

2Simple Network Management Protocol，简单网络管理协议。——译者注

这张图很复杂，它试图展示一切，只用一种颜色却显得力不从心。去掉一些信息或使用多种颜色来突出架构中不同的路径，效果会非常好。

应该用白板

最后一张图作为例子很好地解释了为什么白板是有很用的工具。

创建有效的草图

这些示例图代表我最初和软件团队一起工作，帮助他们更好地以可视化的方式交流软件架构时看到的一些东西。哦，别以为微软Visio能帮上什么忙！它往往只会让事情变得更糟，因为现在人们还要和工具纠缠。通过快速的谷歌图片搜索，我发现了下面这张图3，其中有很多跟我们已经看过的图相同的问题。我敢肯定，你曾看到这样的图。根据我的经验，中心化架构团队喜欢这类东西。

3https://www.google.com/search?q=software+architecture+diagrams&tbm=isch

从谷歌图像搜索找到的一些典型的框图

使用UML可以避免很多这样的陷阱，但现在似乎没有太多人有热情去学习这东西。简单而有效的软件架构草图是每个人都可以完成的，所需的不过是一些简单的建议和一组通用的抽象。