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

转载 2017年01月03日 12:57:15

键盘男的博客地址:

http://www.jianshu.com/users/0ef3dc77079c


2

为什么要组件化、模块化

   

项目存在问题


  • 代码量大,耦合严重

  • 编译慢,效率低

  • 业务开发分工不明确,开发人员要关心非业务的代码

  • 改代码时,可能会影响其他业务,牵一发动全身


优点


  • 架构更清晰,解耦

  • 加快编译速度

  • 业务分工明确,开发人员仅专注与自己的业务

  • 提高开发效率

  • 组件、业务独立更新版本,可回滚,持续集成


3

组件化与模块化

   

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


组件


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




例如,图片上传功能,应该叫“图片上传组件”,而不是“图片上传模块”。因为图片上传从功能、业务上,已经不能往下拆了。


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


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


模块


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




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


两者关系


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


  • 组件从业务角度上不能继续拆分,可替换,可复用;

  • 模块的定义比较笼统,可以是一个Business业务,可以是技术架构中一个业务,也可以是几个组件构成的小功能。


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


4

业务划分

   

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


例如,大众点评,首页已经展示了好多个业务:美食、电影、酒店、休闲娱乐、外卖、机票/火车票..... 这种多业务APP,通常会把业务尽量展示在首页,这种APP大的业务很好划分。美食、电影这类看起来完全不同的业务,笔者称为Business业务。




但并不是这样划分就OK了,好像大众点评这种超级APP,每个Business业务都能分成很多基础业务。例如,美食业务,可以搜索商铺、预约、使用优惠券、点评、签到等;同时,电影业务也有搜索、优惠券、点评等。所以,搜索商铺、优惠券、点评这种基础业务,可以独立出来,被多个Business业务使用。



5

组件与业务

  

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


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



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


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




6

业务与业务

   

情景1


场景:在大众点评订了酒店,入住之后,打开该酒店详情页,大众在“推荐列表”给你推荐若干大保健......


情况1:


前端H(负责酒店业务H):后端D,麻烦给酒店业务单独做个推荐大保健的api。
后端D(负责大保健业务D):大保健业务有api D,你调用api D吧

前端在酒店业务Module,写了调用api D,功能上线。

=============================================================
过了一段时间,大保健业务做了调整,数据变动、改域名等。

后端D:前端H,api调整了,麻烦调用api D改为调用api D1。
前端H:现在好忙,我加班搞吧。

于是前端H加班改代码,还要做单元测试等一系列工作。

=============================================================
又过了一段时间,大保健业务再次数据变动。

后端D:前端H,api D1改成api D2。
前端H:怎么又改.....


本来前端H是做酒店业务的,为了大保健的推荐列表,不得不因为大保健业务调整,而加班加点。再延伸一下,如果酒店业务H还需要调用电影院列表、美食列表.....每个业务的改动,前端H就呵呵了。


情景2:


当然了,要前端不改动,后端保持原来api D也可以的。只不过,会引发下面对话:


前端H:后端D,不过你一直提供api D给其他业务使用,当数据调整时,api D做好兼容我们就不用改了。
后端D:你傻逼啊,兼容多麻烦,我们很忙的,你们不就改一点代码吗?我们还要#&^@&#$"@*#......


维护兼容/对外开放接口确实是一种解决方法,只不过会加重后端开发、运维的工作量,长期来看并不科学。


情景3:


如果在前端业务与业务在独立的情况下,也可以相互调用,那就简单多了:

前端H:前端D,麻烦写一个接口,让其他前端业务可以请求大保健推荐列表。
前端D(负责大保健业务D),没问题,你调用D类getHealthCare(),就会请求大保健推荐列表,并返回你要的数据了。

=============================================================
过了段时间,大保健数据变动。前端D在前端大保健业务D做了api D->api D1改动,并对D类getHealthCare()做了数据兼容,前端H不需要额外改代码。


从上面3个情景看,情景3是最优的做法,前端H并不需要跟后端D对接,大保健业务D改动,后端D不需要通知前端H,只需要跟前端D对接即可。而前端的兼容工作,比后端兼容工作要简单得多。


7

业务之间跳转

   

业务之间跳转,这个话题老生常谈了。无论是Android、iOS,都是URL Schame跳转这种解决方案。原因是url不需要任何依赖,而且可传递参数。


8

业务数据交互

   

无论前端、后端,业务之间数据交互,都是很重要的环节,选用何种合适的方案,就体验架构师的水平了。

未做业务拆分时,直接调用其他业务的代码即可:


-数据直接交互,强耦合-


但业务拆分后,就不能直接调用代码了。两个业务相互独立,代码互不依赖,必须用某种协议(常用json)用数据。


-间接交互,服务中心做数据中转-


如果其他业务需要获取大保健数据,首先大保健业务要注册大保健服务到服务中心,其他业务才可以通过协议调用这个服务。



-业务相互调用-服务中心-


如何注册服务,Android和iOS都有不同的做法,而且方法不止一种。本文仅提供思路,技术细节,会在之后的文章阐述。


其实组件与组件之间,也存在相互调用的情况,可参考这种做法。


9

小结

   

组件化、拆分业务后:


  • 单一职责:开发人员专注于自己的业务

  • 依赖倒置:上层业务依赖下层业务,业务依赖组件,业务之间、组件之间不相互依赖

  • 接口隔离:业务之间调用数据,通过统一的协议与服务中心交互,不调用业务实际代码


代码质量与规范程度明显提高,高内聚、低耦合。业务职责分明,单元测试也更好写。如果业务拆分做得好,可以一个业务一个单独工程编译,不仅大幅提高编译速度,而且业务代码还可以回滚、版本发布等。


一切为了更清晰的架构、更干净的代码^_^


相关文章推荐

APP组件化与插件化华山论剑

目录: APP项目如何与插件化无缝结合(一)  APP项目如何与插件化无缝结合(二)  APP项目如何与插件化无缝结合(三)  阅读这篇文章前,建议大家把前面三章大概看下,内容可以会有点多,有了...

iOS App组件化开发实践

iOS App组件化开发实践 前因 其实我们这个7人iOS开发团队并不适合组件化开发。原因是因为性价比低,需要花很多时间和经历去做这件事,带来的收益并不能彻底改变什么。但是因为...

App工程结构搭建:几种常见Android代码架构分析

原文:http://mobile.51cto.com/abased-386212.htm 关于Android架构,因为手机的限制,目前我觉得也确实没什么大谈特谈的,但是从开发的角度,看到整齐...
  • hpb21
  • hpb21
  • 2015-04-30 21:45
  • 3174

iOS 组件化,插件化,模块化设计思路分析

iOS 组件化,插件化设计思路分析 前言 随着用户的需求越来越多,对App的用户体验也变的要求越来越高。为了更好的应对各种需求,开发人员从软件工程的角度,将App架构由原来...

面向服务体系架构和业务组件的思考

摘要:   在基于面向服务体系架构(SOA)中,“组件化”是一个很重要的概念,如何进行“组件化”开发是搭建企业级业务基础平台时需要考虑的一个重要课题,本文通过建立业务组件(BC)接口模型及内部结构模...

好文章分享--《组件化与业务拆分那些事》

原文地址:http://www.jianshu.com/p/60c1b9ddd8ab 前言最近事情比较多,2个月没写文章了。看笔者圣诞节还在写技术文章,就知道程序猿的生活有多惨淡。上几篇单元测试的文章...

IBM CBM 业务组件化模型

  • 2017-03-05 14:50
  • 77KB
  • 下载

Android项目架构之业务组件化

前言:从个人经历来说的话,从事APP开发这么多年来,所接触的APP的体积变得越来越大,业务的也变得越来越复杂,总来来说只有一句话:这是一个APP臃肿的时代!所以为了告别APP臃肿的时代,让我们进入一个...

CBM组件化业务模型白皮书

  • 2016-03-07 10:48
  • 1.52MB
  • 下载
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:深度学习:神经网络中的前向传播和反向传播算法推导
举报原因:
原因补充:

(最多只允许输入30个字)