组件化开发之模块拆解方案简述

作者: 8bc18a303943 | 来源:发表于2017-03-20 17:55 被阅读264次

组件化开发之模块拆解方案简述
通用组件-时间控件使用方法
使用JIMU组件化方案
iOS组件化
模块化、组件化的深入理解，
iOS：组件化的三种通讯方案
Android组件化和插件化开发
iOS组件化方案实战
Android组件化和插件化开发
Android组件化开发实践笔记

修改记录：

版本	时间	内容	修改人
V1.0	2017.03.27	确定初稿内容	钟杰

术语

业务：指目标用户实际作业涉及的事务，业务最终的目的是完成工作所做的所有事务。

业务场景：指一项任务的过程或子过程，包括业务目标、参与方、操作流程、信息传递过程。在开发过程中对应的是：使用角色、页面流程、数据请求和处理过程等。（所以一个业务场景在app中的表现可能有多个页面跳转流程、多种输出结果）

业务模块：业务模块是指一个或多个业务功能组合在一起形成大的闭环结构的业务处理组织，它有具体的业务场景。

活动：活动是指在一个流程中的一个最小处理单元，该单元必须受限于输入参数，也必须有输出结果的能力。

功能：以某个特定职能为单位，从微观的角度来说是指完成某项职能所必需的一系列有逻辑联系活动的组合，从宏观的角度考虑可以认为，它是一个闭环，有输入条件和输出结果，它处于业务的某一个环节或者本身就是一个业务。在业务功能单一的情况下，特定职能可以等价于某项业务。

native功能、业务功能：两者之间的区别是，从职责范围角度考量，前者没有具体的业务属性，即没有具体的业务场景，而后者有业务场景。从复杂度上来说，前者具有功能简单、职责单一、涉及范围小、复用性强等特点。举例：加载图片功能、打印日志功能、正则验证功能。而后者在一般情况下功能会比较复杂，复用性差，依赖于业务存在，往往一个业务功能必涉及到对业务数据的操作（增、删、改、查）。所以Native功能往往组合在一起成为lib模块，处在依赖结构树中最底层，作为基础lib存在，而业务功能组合在一起就会成为具体的业务模块，业务功能实现过程中往往会使用多个native功能。
一项业务功能可能包含多个native功能和多个活动，一项业务功能代表一项业务，一项业务或多项业务组合为一个业务模块，一个或多个业务模块组合成产品。

功能的操作内容：指的是对业务数据进行增、删、改、查等业务实现过程中，需要从界面接受手动输入或者严格依赖界面才能完成业务的一系列的操作。

界面/页面：该流程中的界面具体是指产品中每一个实际存在的界面。界面作为功能的承载而存在，每个界面包含的N个功能的操作内容展示、N个功能入口。如果界面展示了某个功能的操作内容，则说明该功能和界面是耦合的，具有不可切割的属性，但是功能入口是和该界面没有耦合的（只负责切换流程、切换页面），所有功能入口可以是来自不同的业务模块，也就是业务模块之间解耦。一个页面在一个业务流程中对应多个或全部活动的内容，一般情况下一个页面包含至少一项业务功能的操作内容。
页面分类：
1. 纯功能入口展示页面：只有功能入口，没有包含任一业务功能的操作内容
2. 纯业务操作页面：只有某一个业务的操作内容展示，没有其他的功能入口
注意：业务操作内容中，不是说有的操作内容都会处理操作结果转入其他页面。可能仅是做纯展示，也可能是页面流程的终点。
3. 综合界面：既有某业务功能的操作内容，又有其他的功能入口。

业务流程图：以某项业务为单位，将完成一项业务的所有活动，按照活动发生顺序和选择性判断某个活动输出的结果进行活动流转控制，并通过简单的连线链接所有活动，形成的有序逻辑活动流程。

页面流程图：以某项业务为单位，将完成一项业务的所有页面，按照页面启动顺序和选择性判断某个页面被启动前的参数进行页面流转控制，并通过简单的连线链接所有的页面，形成的有序逻辑页面流程。

一、方案背景

本篇文章的主要内容是简述组件化开发中模块拆解这一环节的工作内容。模块拆解作为组件化开发方案的基础内容，拆解出来的模块也是产品组件化后可配置的内容，模块拆解的结果，会直接影响到产品的业务灵活度。所以本篇文章旨在规范模块拆解的过程和结果，规避模块拆解中可能会出现的错误。

二、使用角色

该方案的涉及的角色有产品人员和研发人员。

产品人员的工作是梳理业务流程，划分出业务边界，得到划分好的纯业务模块，同时根据业务流程绘制该产品的页面流程图。
研发人员的工作是根据页面流程图，梳理业务功能之间的调用关系，这些调用上的关系如果涉及到了两个业务模块，会产生业务依赖，研发人员需要根据业务依赖的程度决定是否拆解产品人员定义的纯业务模块。研发人员也需要根据产品人员定义的纯业务模块的范围大小来决定是否合并一些业务模块组成综合的模块。

三、具体步骤

Step1.产品流程整理

一个产品的研发过程中，首先是业务需求收集和整理，产品人员在这一阶段需要输出的文件如下：

产品业务流程图
说明：每一项业务需求具化到业务整理这一层面，会简化成用N个活动和N个判断通过逻辑组合在一起的流程图。
样式：
图1-泳道图样式
参考资料：
产品经理业务流程图的绘制流程分享
 如何绘制业务流程图

产品页面流程图
说明：绝大部分业务需求需要页面来承载，每个界面责任是承载业务功能和内容，通过业务流程图，可以将每一项业务需求中的页面通过逻辑判断连接起来，输出页面流程图。
注意：在页面流程图中我们罗列的功能都是业务功能。
样式：
图2-组件化开发-页面流程图-模型
参考资料：
谈谈页面流程图

Step2.业务边界划分

为了适应组件化开发，产品高度配置，有两个特定业务模块比较特殊，每个产品中都应该有这两个模块，具体介绍：

shell模块：这个模块是产品门户模块，负责每个产品一些特殊“样貌”的定制，在一个产品中很有可能出现几个业务模块的业务功能在同一界面，而该界面又没有业务功能操作内容，所以从本质上来讲，该页面属于纯功能入口展示界面，那么它是没有业务属性的，这种情况下，你将该界面归于某个业务模块显然不合适，于是就有了shell模块来承载这些需求。
baselib模块：这个模块的定位是工具类，作为工具类，最重要的属性不是承载业务，而是实现功能，而且该功能只完成特定功能。比如log日志打印，正则验证工具类等，打开网页的工具类。

当产品的业务流程和页面流程整理出来之后，将每一条业务流程所包含业务功能进行父业务性质上的属性判断，从而得到某些性质相似的业务功能的组合，这些组合所承载的业务宽度和深度构成了业务范围，于是得到从纯业务角度分析得来的业务模块。如下图：

业务模块：

图3-纯业务模块列表-模型

业务范围模型：

图4-组件化开发-业务范围模型图

Step3.业务模块分解&组合

Step2中已经得到了从纯业务角度出发得到的业务模块列表（图3列表，对应图7中M2层模块），一个业务模块下往往不会只有一项业务功能，理论上每个单独的业务功能都可以称为一个业务模块，这是最小粒度的业务模块，但是并不是所有的业务模块都要求是最小粒度的，需要通过判断调用关系来选择是否向下拆分业务模块。
向下分解原则：只有当某个业务功能有需要被其他业务模块调用的需求后，而且该业务功能可以在独立的情况下运转（是一个闭环结构），我们才会向下分解子业务模块，得到如图7-M3层的业务模块。

业务功能之间的调用关系我们可以从页面流程中直观的梳理出来，以业务流程为单位，将它简化为业务功能时序逻辑调用的简易链条，这个链条可以很轻松的从业务流程图和页面流程图中梳理出来，但是值得注意的是，业务流程图是活动级别的，而页面流程图是页面级别的。

业务功能调用关系-页面流程图上示例：

图5-页面流程图上的业务调用关系示例

注意：绝大部分业务功能会有页面承载，一个页面至少有一个默认业务功能的操作内容或者一个业务功能入口，所以在业务流程图很容易找到如下图中红线所代表的调用关系。一点细微区别是，一个业务模块下的页面流转通常是上一个界面默认功能决定的（当然如果某个界面有的默认业务功能的操作内容，但是操作内容并不包含跳转其他页面的功能，则该页面是纯展示页面），而业务功能入口可以跳转任何业务模块，没有限制，跳转的其他业务模块的表现形式是跳转到其他的页面，相当于切换了页面流程。

业务功能调用关系实例：

图6-跨业务模块-调用关系-模型图

注意：所有的跨业务模块调用关系都需要我们去判断是否符合向下分解的原则。

向上组合原则：当M2层的业务模块中业务功能单一，而且两者组合对产品的功能配置没有影响，那么这样的业务模块可以酌情组合，得到如图7M1层的业务模块。

模型图：

图7-模块分层模型图

说明：

分为3个层级是一种思考模型，方便大家讨论业务模块划分时根据产品的实际需求，可以向上综合、向下分离业务模块，这张图会伴随整个模块化开发的过程，模块配置需求的变动都会映射到该图中。以下是对三个层级的简单说明：

M1：复杂度最高的业务模块，定义为产品模块，这一层级中的模块应该包含有2种或2种以上的业务模块。

M2：单纯从业务角度划分出来的业务模块，每个模块的职责范围必须是一项完整的业务。

M3：从解耦开发角度来拆解业务模块，这一层的业务模块最小粒度就是一个业务功能。

实例：

图8-B端-组件化开发,模块拆解图-实例

当M2层的所有模块都从实际开发角度和业务调用解耦角度去组合分解之后，此时就会产生最终业务模块清单（图9中橘色部分的模块）。在这种思路下产生的业务模块可以支持产品配置的需求，无论是业务层面和代码层面都达做到了解耦。最终得到的模块还是在图4的基础上编辑，这样既方便后期需求变动维护，也能一目了然的知道模块所在层级。