命名规范
eg:SVBxxxx。SVB统一前缀，xxxx业务组件名称
SVBxxxx-yyyy。yyy是业务模块的子模块（待定）
相关说明
凡间：“凡是皆组件的意思”，对基础组件进行管理
基础服务层：这个其实是个虚拟层，有3个基础组件组成“SMGJSManager”、“SMGRouterBox”、“SMGAPPService”
SMGJSManager：与前端交互组件，对JSHandle进行管理
SMGRouterBox：服务化路由，对RouterHandle进行管理
SMGAPPService：APP生命周期处理组件，APPDelegate解耦，对APPHandle进行管理
要求
基于“凡间”开发
业务组件层级结构
业务组件基于“凡间”进行开发。组件之间不进行相互依赖。
业务组件内部设计
业务模块实现其功能后，将进行JS、Router、app生命周期进行配置编码，供APP与其他组件调用
业务组件之间的调用
组件之间不进行相互依赖，通过Handles进行相互调用，实现完全解耦。
（PS：Handles包括jshandles、routerHandles和appHandles）
实施步骤
1.文件隔离
首先我们需要改变工程文件组织结构。之前view/viewController/Model 划分各位文件，改为按模块进行划分，每个模块划分出view/viewController/Model/Network等。
2.抽出业务无关的技术库
尽量抽离更多的技术库，这类库与业务、产品无关，有较强的稳定性。
每个库有自己清晰的边界，彼此不耦合。
3.拆分出公共代码
拆分出很多基础组件和库后，业务之间可能还会存在很多公共代码，这部分代码与产品和业务有关，拆分后其他app基本没有复用的可能。但是确是拆分业务模块前提条件。
如上图所示按View/ViewController/Configure/Foundation/Resource目录结构将公共代码作为一个整体先拆出去。
公共代码层级结构如上图，避免相互引用。
如果公共代码中有相对独立模块，可拆分成技术组件。
4.业务模块独立
最后一步就是拆分业务模块了，拆分业务模块后，能独立运行，其实这里并没结束。将路由、jS、APP生命周期进行配置编码，供APP或者其他模块进行调用。
配置编码完成后才能算业务模块完全独立。
5.撰写说明文档和使用文档
业务组件开发与测试
模块拆分后进行独立开发，可以有两种开发方式：
1：在主工程进行开发，后将代码移到模块代码中。
2：在模块中进行开发，在模块工程中写自测的demo。
建议使用第二种。
模块开发完成进行测试，如果项目中测试人员充足，可在模块demo中进行模块测试。如果测试人员不足可在主工程进行测试。总体根据项目实际情况而定。
业务组件版本管理
业务组件版本有两种方式：
1：根据版本号进行管理，eg：pod 'xxxx','~> 2.0.3'
2：git地址+分支+tag，eg:pod 'TaxServiceTemplate', :git => 'git地址', :branch => 'branch'
因为业务模块存在很大的不稳定性，所以建议使用第二种方式，业务组件版本单独管理，当业务组件修改时，在develop上进行开发，完成后merge到指定（Release）的分支。在主工程代码update，可更新到最新代码。完成发布后业务组件打上对应的tag。
业务组件的思考？
业务组件的效果之一就是个业务模块可以独立运行。
很容易想到的一个改造就是把各个模块拆到不同的 git 中。
好处很多，比如单独的权限控制，独立的版本号，万一发版时发现问题可以及时 rollback 用老版本打包。
但后续开发中体验并不是很好。独立很多业务组件后，每个同学都同时维护着多个模块。每个业务组件修改完成后，要多次执行提交、打版本号以及集成测试等操作，很不效率。
