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

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

概述

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

组件化

组件化是可灵活组合和可定制的前提，是构建大型软件应用的核心思想。组件化的基本技巧是“识别和分离关注点”。内心没有“关注点”概念的开发者，写代码时比较随意，在实现功能时无心识将多个关注点掺杂在一块儿，当关注点发生变化须要重组时，“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接口进行数据获取和存储的数据同步组件。所以，大数据存储设计、数据同步对于订单导出的总体设计尤其重要。

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

建立组件，定制组件，设计和复用组件协做结构，组合出更大结构的组件，从而可以建立更大型更综合的大规模软件系统。

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