架构师必看：软件架构图的艺术

要点

1. 设计软件架构图并非一件轻而易举的事情，即使是很简单的一个架构图也可能会出错。有意义且具备一致性的架构图有助于为不同的利益相关者澄清事实，并达成共识。
2. 在大多数情况下，问题的根源并不在于是否使用了一门有效的架构描述语言（比如UML），而在于低估了架构图的重要性，转而依赖不恰当或不具备一致性的指导性原则，或者缺乏架构思维。
3. 在创建架构图的过程中，试着混合使用自动生成的图元和手动创建的图元，这样可以减少工作量，并且可以表达出各方面的关注点，覆盖到系统的各个层面。
4. 系统不断地发生演化，要维护更新架构图需要花费额外的精力。我们需要知道如何有效地应对这种情况，同时能够保持架构图的一致性和健壮性。
   现代的软件架构带来了更多的复杂性，这些都反映在了架构图上。

曾几何时，我们的每一个软件项目都需要一个架构图。不管我们是否遵循正式的架构模型（比如Kruchten 4+1、Rozanski & Woods等），都有必要通过图表来对应用程序的某些部分进行文档化。在软件架构里，这些图表一般都是按照某些视图进行设计的，这些视图本身就是模型的一部分，不过在这篇文章里，我倾向于使用架构图这个术语，因为它看起来不是那么正式，至于其他方面的内容并不会在这篇文章里涉及到。

作为一个软件架构师和技术培训师，从我的经验来看，不同项目之间以及同一个团队的不同开发人员之间创建架构图的方式也是很不一样的。我看到过很多问题，比如一致性问题、碎片化问题、信息粒度大小的问题，以及图表的外观问题。相比架构模型的正式和标准化，架构图倒是不必要那么正式或者遵循什么标准。

相关厂商内容

解读百度PB级数据仓库Palo开源架构 Snapchat大规模个性化推荐引擎解密 微信 交广告核心架构与图计算存储 摩拜单车：如何通过机器学习等技术提高单车运营效率 获取面向人工智能、机器学习和深度学习的最新工具、框架
相关赞助商

不过，架构图必须是自描述的，并且要具备一致性和足够的准确性，能够与代码相呼应。这也就是为什么架构师或软件工程师在创建架构图时需要依赖各种指导性原则，因为它们是理解应用架构（比如结构、元素、关系、属性、原则）的基石，同时也是具有不同技术背景和关注点的利益相关者的沟通基础。

当前架构图的不足之处

在深入展开说明之前，我想引用一句英语谚语：“一张图片胜过千言万语”。Wiki上解释说，“这句谚语的意思是，一个复杂的想法可以通过一张静态的图片表达出来，或者图片可以表达一个主题的意思，又或者图片比文字描述来得更加直接有效”。对于架构图来说也是一样的：如果它所导致的疑问比它能解释的问题还要多，那么它就不是一张好的架构图。一张好的架构图不需要多余的文字解释！