你好,我是七牛云许式伟。
在上一讲 “加餐 | 实战:画图程序的整体架构” 中,我们结合前面几章的实战案例画图程序来实际探讨我们架构思维的运用。这一篇虽然以加餐名义体现,但它对理解怎么开展和评估架构工作非常关键。 在架构设计中,我们会有一些难啃的骨头。其中最为典型的,就是全局性功能。全局性功能的特征是很难被剥离出来成为独立模块的。我们仍然以大家熟悉的 Office 软件作为例子:
读盘 / 存盘:每增加一个功能,都需要考虑这个功能的数据如何存储到磁盘,如何从磁盘中恢复。
Undo/Redo:每增加一个功能,都需要考虑这个功能如何回滚 / 重做,很难剥离。
宏录制:每增加一个功能,都需要考虑这个功能执行的结果如何用 API 表达,并且得支持将界面操作翻译成 API 语句。
……
也有一些功能看似比较全局,但实际上很容易做正交分解,比如服务端的所有 API 都需要鉴权,都需要记录日志。它们似乎有全局性的影响,但一方面,通常可以在 API 入口统一处理,另一方面就算只是提供辅助函数,具体的鉴权和记录日志都由每个 API 自行处理,心智负担不算太高。所以对于这类功能,我们可以不把它归为全局性功能。
正因为需求交织在一起,全局性功能往往难以彻底进行正交分解。但对于架构师来说,难不代表应该轻易就放弃对正交分解的追求。