知识卡片
没有连线的架构,很可能不是架构
内容
一幅汽车”架构图”画出发动机、座椅、车轮的位置,看似符合大多数架构定义的元素,却几乎无助于理解汽车如何工作——为什么发动机和传动装置总在一起?车必须有4个轮子还是3个也行?图只描述了”包含关系”(座椅在客舱内)和”接近关系”(发动机和传动装置紧挨着),这两种关系本质上就是缩进的项目符号列表的图形投影,无法传达组件在系统里的作用和行为。图中缺失的关键要素是”连线”:没有连线就表现不出丰富的关系,Kent Beck半开玩笑称”线框+连线+标签”才构成完整的建模语言(GML),”连线要比线框有意思得多”——集成出错的地方永远在两个组件之间,强耦合还是松散耦合的答案也在连线上,区分良好架构和大泥球架构的关键同样是连线。
结构图:
flowchart LR
A["只有包含关系<br/>(座椅在客舱内)"]
B["只有接近关系<br/>(发动机紧挨传动装置)"]
A --> C["=缩进项目符号列表的图形投影"]
B --> C
C -.缺失.-> D["连线:表达关系的语义(数据流/调用/依赖)"]
D --> E["没有连线的图,很可能不是架构"]
参考来源
- 位置:《架构师应该知道的37件事》第3章《沟通》之"3.7 绘制连线"·"3.7.1 注意连线"与"3.7.2 元模型"(源文件:_epub-src/OEBPS/Text/chapter003.html)
- 结论依据:原文说明"图中缺失的关键元素就是组件之间的连线。没有连线,就很难表现丰富的关系……如何区分结构良好的架构和大泥球架构?当然是通过连线",并指出该图只有"包含关系"和"接近关系"两种,直接支撑本卡结构图。
- 原始内容:只基于包含关系和接近关系的图通常就像缩进的项目符号列表:子项目列表包含在外部项目列表里,同一层级里紧挨着的项目符号之间就是接近关系。