软件设计要素初探：组件化思想

Posted 2020-12-30 lovesqcc

在 “软件设计要素初探” 一文，尝试从软件设计的整体角度，综合讨论了软件设计的各种要素。本文讨论用于系统划分的组件化思想。

概述

将整个系统划分为若干正交的紧密关联的子系统，以及高内聚低耦合的小而美的模块与微服务，理清职责、交互与边界。划分的基本原则是“识别、分离和组合关注点”。每个子系统必定有其核心关注点和基础关注点，而基础关注点中交叠的部分，即是子系统交互定义的基础。

组件化

组件化是可灵活组合和可定制的前提，是构建大型软件应用的核心思想。组件化的基本技巧是“识别和分离关注点”。心里没有“关注点”概念的开发者，写代码时比较随意，在实现功能时无意识将多个关注点掺杂在一起，当关注点发生变化需要重组时，“for-ififelseif-for-ifelseif-switch”的噩梦开始诞生了。而善于“识别和分离关注点”的开发者则会想办法把这些关注点解耦开，实现成简洁可组合的短小函数、方法和类，并置于该归属的地方。组件化的另一个基本技巧是“面向接口编程”：先创建所需要的组件接口，然后创建基于组件接口的应用骨架，最后根据需求和场景创建和注入具体实现。尽管有时这种做法显得“有点过度设计”，却更有易于理解系统流程。

组件化可以从不同粒度上进行。

(1) 单个应用。单个应用内的组件化，主要是将单一关注点的逻辑功能组件化，能够灵活组合和配置；亦可将紧密关联的小组件串联成更大粒度的更实用的组件。比如一个订单导出应用，其流程是：订单搜索 -> 订单详情获取与拼接 -> 订单过滤 -> 详情数据格式化 -> 结合报表模板生成报表 -> 上传报表文件。将每个步骤定义成一个组件接口(订单搜索组件接口、获取详情组件接口、订单过滤组件接口、订单详情格式化组件接口、报表生成器组件接口、上传文件组件接口)，再定义一个全局控制器，将组件接口串联成导出流程，而具体的导出实现只要传入指定组件接口的具体实现即可。订单搜索可以从DB查询，亦可以从 ES 查询；订单详情可以从API接口获取，亦可以从Hbase获取。为保证大批量数据导出的性能，减少业务数据库和业务接口的压力，推荐使用 ES + Hbase 组合。

组件化之后，亦容易实现可定制化。 比如有的导出只需要导出 ES 表里的记录；有的导出只需要导出 Hbase 表里的记录；而略微复杂的导出则需要从 ES 和 Hbase 同时获取数据。这就需要根据参数配置对组件进行灵活组合。

(2) 多个应用构成了更大粒度的领域服务组件。一些互联网企业开始推行“服务化架构”，每个服务化工程就是一个组件。比如订单管理组件可由订单搜索/订单详情/数据同步/发货组件/订单导出组件等组成；交易服务组件可由下单服务组件、订单管理组件、逆向交易组件以及辅助组件(比如交易消息推送组件、核销组件)组成。

(3) 多个特定领域服务组件构成更大粒度的行业服务。比如交易、营销、商品、会员等服务组件可构成电商SAAS的云服务能力。比如拥有完整微商城能力并致力于移动零售领域的有赞云。

组件协作

尝试从更大范围的系统领域来思考和设计组件以及组件之间的协作结构。比如订单导出需要从ES和Hbase搜索订单和获取订单详情，而ES和Hbase的订单数据则依赖于从消息、DB或API接口进行数据获取和存储的数据同步组件。因此，大数据存储设计、数据同步对于订单导出的整体设计尤为重要。

订单导出的比较棘手的一个问题是，数据源通常来自于多个分散的业务表，这样导致同步设计重而且不灵活。如果制定一种标准，需要导出的字段必须落在下单表的字段或扩展字段里，那么就可以有效地解决数据源分散的问题，而集中精力于解决导出可扩展可配置的问题。此时，下单、同步、导出成为密切关联的一体化设计。当从单系统上难以寻求解决方案时，不妨从更大系统范围去发现。

创建组件，定制组件，设计和复用组件协作结构，组合出更大结构的组件，从而能够创建更大型更综合的大规模软件系统。

设计优良的系统，通常有一个清晰的组件化的骨架。组件化的骨架，就是可定制和可扩展的基础支撑。