京东云开发者|软件架构可视化及C4模型:架构设计不仅仅是UML

软件系统架构设计的目标不在于设计本身,而在于架构设计意图的传达 。图形化有助于在团队间进行高效的信息同步,但不同的图形化方式需要语义一致性和效率间实现平衡 。C4模型通过不同的抽象层级来表达系统的静态结构 , 并提供了最小集的抽象建模元素 , 为设计人员提供了一种低认知负载、易于学习和使用的高效建模方式 。
 1 为什么要进行架构可视化?软件系统架构设计的目标不在于设计本身,而在于架构设计意图的传达 。如果不能清晰、一致的在干系人间进行设计意图的同步,即使再好的设计也只是空中楼阁 。软件架构设计本质上也是一种抽象和建模的过程(对模型和抽象的本质参考文章《 领域驱动设计开篇 》),软件架构设计模型的表达有多种方式:图形化、语言和文字 。绝大部分场景下,图形化在架构设计的表现力层面效果更佳 。因此,对于软件系统架构进行可视化表达是有价值,且是必要的 。
软件架构可视化的方式有多种,不同的团队有不同的实践方式,最为常见的由如下几种:
?线框图:通过线框图和连线表达架构元素及之间的关系?UML:统一建模语言,表达系统的静态结构和动态行为?草图:非正式的图形【京东云开发者|软件架构可视化及C4模型:架构设计不仅仅是UML】不同的可视化方式各有优劣 , 以下部分将对不同的表现形式进行说明
1.1 可视化方式-线框图线框图是最为通用的可视化表达方式之一 , 架构师或设计人员大量的架构图 , 比如技术架构、功能架构、数据架构、逻辑架构等等都通过线框图的形式表达 。该种可视化方式的优势是:
?建模工具多样化:你可以基于Viso、Drawio、PPT等任何一款支持线框图的软件进行建模工作?学习成本低:设计人员几乎不需要进行专门的建模语言以及建模工具的学习,门槛较低但,基于线框图表达软件系统架构存在的问题也非常明显:语义的一致性问题
你可能自己画过很多软件系统架构图,也可能参与评审过其他团队的架构图,我相信,对你而言并不是的所有的图都是“清晰且易于理解的” 。举个简单的场景,如果我们在百度搜索 “架构图” ,你可能得到以下结果:

京东云开发者|软件架构可视化及C4模型:架构设计不仅仅是UML

文章插图
各式各样的 “架构图”:不同形状和颜色的图形元素、不同形状和颜色的连线、不同的意图 。
我们可以看出:线框图虽然简单,但其其图形化的语义一致性是大问题 。虽然都是通过线框表达软件系统架构,但不同的人可能使用不同的元素、不同的颜色、不同的连线和分层等等,线框自由表达的灵活性和图形化语义的一致性存在潜在冲突 , 最终都会阻碍架构设计意图传达 。
1.2 可视化方式-UMLUML是统一建模语言,相比于线框图而言,其优势是在软件建模层面提供了一致性的建模元语言 。简单来说,UML提供了大家达成一致的(UML支持扩展的场景除外)建模元素 。如果团队成员比较熟悉UML,那么通过UML表达的系统架构图天然具有认知一致性 。
丰富灵活的建模元语言在提升语义一致性的同时,也必然会导致复杂性的上升 。掌握UML具有一定的学习成本,而熟练的应用对研发人员也提出了更高的要求 。基于 Simon Brown给出的数据,实际情况只有少数团队真正使用UML 。不论是UML的复杂度和学习成本原因,还是敏捷化下对UML的排斥 , 很多团队都放弃了UML 。
我们不能否认UML的价值 , 基于统一建模语言能够更有效的进行架构设计的信息传递和沟通,也能基于UML提供的详细的模型图元素进行充分的设计表达 。团队中是否要基于UML进行沟通需要权衡,虽然UML不能表达你所要传达的全部的架构信息,但其在某些维度的表达相对比较适合 。
?表达流程和工作流可以采用UML活动图?表达运行时的交互可以采用UML时序图?表达领域模型或者设计模式可以采用UML类图?表达状态转换可以采用UML状态机?表达系统的部署结构可以使用UML部署图1.3 可视化方式-草图架构可视化另一个非常常见的方式是:草图 。草图是一种非正式的、易于快速沟通的图形化方式 。团队基于特定的场景,可以通过草图的形式进行快速的沟通,以便高效的在干系人间拉齐关键信息 。
但,草图的劣势与线框图一样:语义一致性低
我们可以在白板上 “随心所欲” 的画各式各样的草图 , 草图上的元素、连线,又或者布局都可能是涌现式的、临时性的,这些草图的价值在于 “会话周期内的高效沟通” 。如果干系人没有完全参与到草图的讨论,又或是后置查看 , 大概也很难精准捕获这些草图所要表达的设计意图 。

推荐阅读