博客
关于我
强烈建议你试试无所不能的chatGPT,快点击我
从架构可视化入门到抽象坏味道
阅读量:4225 次
发布时间:2019-05-26

本文共 2222 字,大约阅读时间需要 7 分钟。

抽象的坏味道

说过,C4说穿了就是几个东西:关系-线、元素-方块和角色(角色不过是图形不同的方块)、关系表述-线上的文字、元素的描述-方块里的文字,虚线框(如前文所说,在C4里面虚线框的表达力被极大的限制了)。

这些东西一点都不新,我们自己随便找个白板,无非也是用这几个东西来表达架构,它的优点在于引进了一些分层,帮助我们理清思路、也有利于可视化给别人看。

换言之,C4不能帮你做好架构设计,但是它能暴露出你设计中的问题,以便于被自己或其他人纠正。

可视化的威力就在这里,但根据我的经验,即便你用上了C4也不见得就能表达清楚,不过好消息是,我们终于可以聊一些高级的表达问题了。

可视化之后,我们能看到自己的表达问题,大概的问题有两个:抽象层次和抽象粒度。这个是表达方面永恒的问题,也就是软件设计永恒的问题,没有万灵丹,但是用上了可视化手段之后还是有机会让生活更美好一点的。

这两个问题可能太抽象了,不容易意识到,那我们可以看图,从图上的具体表现来发现坏味道。一般会有几个迹象表明我们有可视化的坏味道:

  1. 一张图上过分密密麻麻的线
  2. 一张图上太过多元素(也就是方块)
  3. 一张图上太少的元素,比如角色特别少
  4. 每个图上文字表达不契合,有的太泛泛,有的太细节
  5. 无限制的画更多张图,基本上也就失去了使用图形化表达的意义

那么对应的手段就有:

合成更大的元素

当我们意识到有密密麻麻的线、太多的元素,闻到这个味道的时候,可以考虑是不是该把里面的一些元素合成更大的元素了。Component可以合成Container,Container可以合成System,这样就会分成更多的图,每张图就变得没那么多线和元素了。

紧接着会面临下一个问题:怎么合成一个更大的系统,Container是明确的,所以Component合成Container不是问题,问题是Container怎么合成一个系统,为什么是这些Container合成这个系统,而不是另外几个?或者多加几个、减几个?

这个问题没有标准答案,但是有一些其他的框架可以提供一些思考的维度。

比如可以结合akf扩展立方来思考。

(akf扩展立方)

X轴就比较容易,一方面从容器本身的描述来看设计上是不是支持横向复制的,另一方面则是看部署图。

Z轴相对难一些,只是比较偏技术。比如当技术上有性能瓶颈,则需要注意这一个维度,有时不得不搞出一些特殊的容器出来,有时已经存在这些容器了,他们可能单独属于一个系统(类似于大数据分析的系统),或者一个系统的某一个局部(这就是前面提到的虚线框表达力被限制的地方)。

Y轴给人的感觉是最容易操作的,但实际上却是最难做好的,Y轴的背后是业务,往往我们觉得就按业务切成多张图就好了。这种想法就表现出我们往往意识不到业务的真正难度,于是总在这里出问题。如果你能跨过这个心理障碍,决定去认真做一下,那么也有一些工具可以帮助我们做好。

(领域模型与架构设计)

最经典的工具组合就是求助于DDD,结合康威定律和步速,考虑维护的团队、使用的角色、变化的节奏,这块展开就复杂了,有机会再聊。

这里说一个最简单的做法:按照用户角色分。同一种角色,由于其在公司里的职能、职责都是已经被定好的,天然在系统上就有一种隔离性。比如招聘专员、会计、出纳,他们使用的系统肯定是不一样。

但说简单,其实也不简单。我见过一些图,上面的角色只有两个,内部用户和外部用户。而另一些图,细化到了个人的级别,或者把职级都放上去了。所以无论再简单的原则,最后都会掉进抽象的坑。

画一些共识图来忽略掉一些通用的元素

有时候合成了更大的元素,元素依然很多,线条依然很密。画多张图也不够切分的。这个时候我们可以求助于共识。

人与人交流,如果已经有一些共识存在就可以少废很多话,共识多到一定程度只需要确认一个眼神就完成交流了。所以毫无疑问,做好共识管理,可以大幅简化我们的架构图。

所以在我们做架构可视化的时候,经常会先画一个技术共识图,比如以一个能力建设的数字平台为例,我们就画了一个下面这样的技术共识图:

(技术共识图)

在后面画具体的图时,就可以省略掉一些共识的元素,像nginx和数据库就没有了,可以更关注在业务上,而不是技术上。

通过制定主题,限制文字的抽象层次

其实上面的技术共识图就是类似的做法,只是用于技术方面,如果用于业务方面,我们可以用一些抽象的名词或动词来代替一类业务,比如下图:

(数字平台系统景观图)

上图是一个系统景观图。当前这个主题是希望人们能一眼看清楚这个系统里面的相关角色都在使用什么系统,他们关注什么,职责是什么。至于具体学什么,怎么学的,都不是那么重要。所以我们就用学习一词代表了一系列的业务。

当主题确定的时候,很多纷杂的信息就没有了。一定要克制住自己试图在一张图上表达足够多信息的冲动。

只画重要的图,剩下的交流的时候再画

除了像上面说的,不要试图在一张图上给他足够的信息。同时也不要试图把所有的信息都表达出来。

绝大多数的图可能只在交流具体业务的时候才画,推荐使用动态图。

总结

即便有了C4这么,好用的可视化工具。我们依然会看到,自己会掉进抽象的坑。所以在使用的时候一定要注意坏味道,经常自查是不是犯了抽象层次和抽象力度的错,才能做好可视化。这件事上,没有谁能幸免,所以要时常自省,与诸君共勉。


文/ThoughtWorks仝键

更多精彩洞见,请关注微信公众号:ThoughtWorks洞见

转载地址:http://zjdqi.baihongyu.com/

你可能感兴趣的文章
POJ 3363
查看>>
[LeetCode] 849. Maximize Distance to Closest Person @ python
查看>>
axi总线介绍
查看>>
Linux内核中ioremap映射的透彻理解
查看>>
ffs的另外一种实现方法
查看>>
strtol的用法
查看>>
工作队列的使用
查看>>
让vim显示空格,及tab字符 vim 多行注释
查看>>
利用mmc_test.c研究mmc模块
查看>>
tasklet、wait_queue、completion、work_queue用法总结
查看>>
int (*func(int)) (int *,int)
查看>>
在Ubuntu上下载、编译和安装Android最新内核源代码(Linux Kernel
查看>>
Linux内核同步机制API函数:宏:spin_lock_init ( )
查看>>
driver_register 理解
查看>>
copy_from_user && copy_to_user
查看>>
device_register
查看>>
Android上C++对象的自动回收机制分析
查看>>
从spin_lock到spin_lock_irqsave
查看>>
sdio 驱动
查看>>
vim 常用用法
查看>>