架构随笔系列—如何理解软件架构中的“组件”

在软件架构的讨论中，一个屡屡被提及的词是“组件”，它被用来指代一块独立的代码，有时候也被描述为模块、服务或者框架，含义模糊且容易混淆。姑且可以认为它们是泛“组件”概念。

之前在IBM接触过透视问题的三个维度的思维模型（图1），功能层面（Functional Aspect）/ 运行层面（Operational Aspect）构成第一个维度，应用级别（Application Level）/ 技术级别（Technical Level）构成第二个维度，逻辑视角（Logical Perspective）/ 物理视角（Physical Perspective）构成第三个维度。从三个不同维度去分析，有助于更全面地解构一个问题。

可以按照这个框架，展开聊聊泛“组件”概念。
1.功能层面（Functional Aspect）vs 运行层面（Operational Aspect）
在这个维度上，”组件”会有代码的功能划分最小单位和代码的部署运行最小单位两层含义。比如通常说的功能模块就属于前者，微服务则属于后者。
2.应用级别（Application Level）vs 技术级别（Technical Level）
在这个维度上，”组件”分别可以代表承载具体业务的应用，或者承载通用技术能力的中间件。比如用户中心和消息队列。
3.逻辑视角（Logical Perspective）vs 物理视角（Physical Perspective）
在这个维度上，”组件”会有逻辑概念和物理实现上的区分。比如”数据库”属于一种逻辑概念，MySQL就是一种物理实现。

把这三个维度结合在一起，每一个泛“组件”概念，都可以找到相应的位置（图2）。

当我们在聊模块（Module ）或者包（Package）的时候，其实是在逻辑上对”组件”的业务功能进行了抽象；当提到开发库（Library）， 其实是代表“组件”在功能层面提供一些了一些通用的技术能力；其他的也类似， 就不一一列举了， 需要注意的是框架（Framework）这个概念比较特殊，横跨了功能和运行两个层面，有的框架（如VUE）侧重功能上的定位，有的框架（如Spring Cloud）则侧重在运行时的定位， 这个就要具体问题具体分析了。

这样对比之后，似乎这些泛“组件”概念就比较清楚了。也许会有人问，这样咬文嚼字有意义吗？如果你只是完成代码的实现，那区分不区分这些概念问题不大，但如果要进行整体架构设计，则意义也许不同，这会让你的描述更准确、架构图更清晰。