5a1757ba223dd939d7cd85a54b3db5be
App 组件化与业务拆分那些事

今天跟大家聊聊 App 项目的组件化与业务拆分。

如果上Google搜“App模块化”、“App组件化”,可以出现一堆文章教你“如何组件化”、“组件化用到什么技术”,笔者经常搞不清他们说的“组件”、"模块"、“业务”到底怎么划分,很多作者对这几个概念都有不同的理解。这导致笔者当初在搜集这方面资料,非常尴尬,每看一篇文章都有地方跟之前的文章冲突,也不知道谁对谁错。

本文会从业务的角度,给大家讲讲为什么要拆分App业务,如何拆分,以及优点等等。

为什么要组件化、模块化

项目存在问题

  • 代码量大,耦合严重
  • 编译慢,效率低
  • 业务开发分工不明确,开发人员要关心非业务的代码
  • 改代码时,可能会影响其他业务,牵一发动全身

优点

  • 架构更清晰,解耦
  • 加快编译速度
  • 业务分工明确,开发人员仅专注与自己的业务
  • 提高开发效率
  • 组件、业务独立更新版本,可回滚,持续集成

组件化与模块化

组件、模块,中文字面意思相近,在英文上都可以翻译为"Module",加上Android Studio上,library被称为"Module",这就不难解释为什么我们谈到“组件化”、“模块化”,两者之间的区别相当的模糊。

组件

App工程上所说的 组件,应该翻译为“Component”,意思是组件、部件、元件。在电子电路中,电子元件是电子电路中的基本元素。在App工程上,组件是构成业务或者功能模块的基本单位。原则上,组件与组件之间互不依赖。

组件,components


例如,图片上传功能,应该叫“图片上传组件”,而不是“图片上传模块”。因为图片上传从功能、业务上,已经不能往下拆了。图片上传可能使用七牛sdk,或者又拍云sdk。无论图片上传组件用七牛sdk,还是又拍云sdk,都不会影响这个组件的功能,因此组件具有可替换性;同时,图片上传组件可以被多个业务使用,因此组件具有可复用性。由于sdk只是技术细节,它跟业务并没有关系。在业务架构图上,也不会出现“xx sdk”,因此我们说图片上传组件不能拆分了。

同理,日志功能,叫“日志组件”,不叫“日志模块”。

模块

模块翻译为“Module”,字面意思。模块由多个组件构成,它可以实现一个独立的功能,甚至业务。

例如,大众点评的美食功能,是一个业务,可以叫“美食模块”,习惯上叫“美食业务”。它可以拆分更小的模块:搜索、签到、评论等。

两者关系

从上面的阐述可以得出,一个工程,由多个模块组成,每个模块由多个组件构成。但很多时候,两者界限还是相当模糊。例如“日志组件”称为“日志模块”,也没有违和感。

  • 组件从业务角度上不能继续拆分,可替换,可复用;
  • 模块的定义比较笼统,可以是一个Business业务,可以是技术架构中一个业务,也可以是几个组件构成的小功能。

无论是组件化还是模块化,目标都是把臃肿的工程,拆分为更小的部分,解耦各种复杂的逻辑,便于代码管理。

业务划分

一个产品的业务,其实是在规划产品功能,或者做产品原型时,已经定好了(如果连产品或者老板都没这概念的话,我们还是算了);如果后端牛逼的话,他们也会做业务划分,每个业务部署到独立的容器、虚拟机、服务器。所以,我们做业务划分时,可以咨询后端,也可以咨询产品经理。

例如,大众点评,首页已经展示了好多个业务:美食、电影、酒店、休闲娱乐、外卖、机票/火车票..... 这种多业务APP,通常会把业务尽量展示在首页,这种APP大的业务很好划分。美食、电影这类看起来完全不同的业务,笔者称为Business业务。
大众点评-首页
但并不是这样划分就OK了,好像大众点评这种超级APP,每个Business业务都能分成很多基础业务。例如,美食业务,可以搜索商铺、预约、使用优惠券、点评、签到等;同时,电影业务也有搜索、优惠券、点评等。所以,搜索商铺、优惠券、点评这种基础业务,可以独立出来,被多个Business业务使用。

组件与业务

上文提过,多个组件构成一个模块,当模块相当于业务时,就是说该业务由多个组件组合而成。

还是拿大众点评做例子,点评基础业务,发布点评需要上传图片、网络提交、记录本地日志等,那么需要调用上传图片组件、网络组件、日志组件等。


不仅仅点评业务调用,所有业务都会调用这些组件。于是,业务架构如下:

Business业务 -> 基础业务 -> 各种组件

业务与业务

情景

top Created with Sketch.