“简单性和模块化是软件工程的基石，分布式和容错性是互联网的生命。”
—— 万维网发明人 Tim Berners-Lee
随着移动平台的迅速发展，Android软件开发慢慢趋向复杂和臃肿，为了降低移动软件复杂性和耦合度，同时也为了适应模块重用、并行开发测试等等需求，组件化/模块化在 Android 平台上变得势在必行。
在《 Java 应用架构设计：模块化模式与 OSGi 》一书中提到：模块化是一种处理复杂系统分解为更好的可管理模块的方式。组件化和模块化是当前软件开发中常用的一种架构思想。
上面描述可能不够直观，我们做一个类比：
我们可以把软件看做一辆汽车，开发一款软件的过程就是生产一辆汽车的过程。一辆汽车由发动机，变速箱，车架，车轮等一系列模块组成，同样，一款商业软件也是由各种不同的模块组成。
汽车的这些模块是由不同的工厂生产的，一辆车的发动机可能是由位于德国的工厂生产的，它的自动变速箱可能是位于日本的工厂生产的，车轮可能是中国的工厂生产的，最后交给工厂统一组装成一辆完整的汽车。这就类似于我们在软件工程领域里说的多团队并行开发，最后将各个团队开发的模块统一打包成我们可使用的App 。
解耦，复用；
降低维护成本，提高开发效率。
继续我们刚才汽车的类比：一款发动机、一款变速箱都不可能只应用于一个车型，比如同一款 Jatco 的 6AT 自动变速箱既可能被安装在 BMW 的车型上，也可能被安装在 Mazda 的车型上。这就如同模块化的复用性。
我们可能需要开着车走雪路，为了安全起见往往我们会将汽车的公路胎升级为雪地胎；轮胎可以很轻易的更换，这就是我们在软件开发领域谈到的低耦合。一个模块的升级替换不会影响到其它模块，也不会受其它模块的限制；同时这也类似于我们在软件开发领域提到的可插拔。
Oasis Feng 在 MDCC2016谈及“模块化思想”，提到了“提炼和划分”，其实就是将业务模块层的各个功能业务拆分层独立的业务模块。所以我们进行模块化的第一步就是业务模块划分，但是模块划分并没有一个业界通用的标准，因此划分的粒度需要根据项目情况进行合理把控，这就需要对业务和项目有较为透彻的理解。
鲸技术在实践组件化与模块化架构思想的过程中，对于项目进行了如下分层设计
鲸钱包App分为三层，从下往上分别是：
基础组件层：顾名思义就是一些基础组件，包含了各种开源库以及和业务无关的各种自研工具库。
业务组件层：这一层的组件是基于业务层特性封装的通用组件，包含消息总线EventMessage，数据模拟组件DataSimulator等等。
业务模块层：根据业务场景，我们拆分了用户模块，产品模块，交易模块，资产模块等。
汽车发动机和变速箱等模块都由各自不同的工厂生产，那么带来一个问题：如何保证各个零配件和模块在总装工厂完美无瑕的对接呢？这也是项目实践过程很重要的一个问题：统一的规范和标准。
同样软件的模块化拆分之后，使得各层级模块分散性增强，导致项目的不可控因素的增加，从而影响软件的质量。软件工程为项目设计很多优秀的架构来规避分散性的问题：比如：MVC，MVP，MVVM等
这些架构思想保证了我们每个模块由了足够明确的开发规范和标准。细致到了每一个类应该放到哪个包下，哪个类具体应该负责什么职责等等。这对于我们的 Code Review、接手他人的功能模块等都提供了极大的便利。
鲸技术在模块化的推行期，统一遵循MVP的设计模式（以供参考）
View Layer: 只负责 UI 的绘制呈现，包含 Fragment 和一些自定义的 UI 组件，View 层需要实现 ViewInterface 接口。Activity 在项目中不再负责 View 的职责，仅仅是一个全局的控制者，负责创建 View 和 Presenter 的实例；
Model Layer: 负责检索、存储、操作数据，包括来自网络、数据库和SharedPreferences的数据；
Presenter Layer: 作为 View Layer 和 Module Layer 的之间的纽带，它从 Model 层中获取数据，然后调用 View 的接口去控制 View；
Contract: 契约类 Contract 来统一管理 View 和 Model的接口，使得某一功能模块的接口能更加直观的呈现出来，这样做是有利于后期维护的。
组件化/模块化是一种与技术无关的架构思想，在不同领域，不同层面都有广泛的应用，它减少了内部循环依赖，减少了耦合，提高了设计的效率，鲸技术分享了Android模块化之路的实践，希望和大家共同探索模块化思想的魅力。
