设计目的
- 支撑前期APP快速的迭代，并且为后期重构创造条件
- 提升代码的可复用性
- 实现组件化、模块化开发
- 树立代码规范，引导开发流程
- 提升代码可维护性（灵活、扩展性高、可读）
设计原则
- 模块内高内聚
- 模块间低耦合
- 模块单一职责
- 模块可独立运行
- 模块可移植
- 模块可插拔
组件聚合原则
- 复用/发布等同原则（为复用性而聚合）
- 共同闭包原则（为可维护性而聚合）
- 共同复用原则（未避免不必要发布而拆分）
组件依赖原则
- 无环依赖原则（依赖关系中无环）
- 稳定依赖原则（依赖关系指向更稳定的一方）
- 稳定抽象原则（越稳定越抽象）
App通用架构图
- 基础组件层
- 通用业务组件层
- 业务层
- App壳
基础组件层
- 每个模块功能单一
- 不包含业务逻辑
- 模块互相独立，没有依赖关系
- 组件化，模块化良好，代码可复用程序高
通用业务组件层
- 对基础组件模块的封装
- 通用的业务逻辑下沉
- 通用的App UI相关组件
- 依赖基础组件层
业务层
- 根据业务及功能，划分多个相对独立业务模块
- 业务模块之间，减少互相依赖
- 业务模块互相调用，通过Router组件解耦
- MVC/MVP/MVVM
模块间通信
- 上下级模块通过门面类通信
- 同级别模块通过接口通信
MVP架构
基本结构
- model 数据实体，数据处理层，包括本地，网络数据的获取、处理、传输、存储
- view UI层，主要完成数据的UI显示、用户交互、事件转发
- presenter 业务逻辑的具体实现，view与model交互的桥梁
优点
- 一个功能拆分为M、V、P 3部分，M、V进行了解耦
- 组件之间交互，都是通过接口实现
- UI与逻辑分离，可方便进行代码单元测试
- 结构简单，学习成本低
代码结构
- 基础组件库模块
- 通用业务组件库模块
- 每个业务模块对应一个模块，N个业务模块
- App壳模块
应用框架
概述
框架一般是针对于某一方面或领域的重用性和可扩展性非常好的半成品，是一种特殊的软件，我们在工作中通过将许多方面的可重用的工具类，公共类，基础类等抽象出来，即可形成一些可重用的框架
目的
- 提前为后期业务开发做支撑准备
- 框架可独立演进
- 项目技术沉淀，可分享其他项目使用
业务架构图
通用框架能力
- 地图能力封装
- 开屏广告封装
- 状态栏通知封装
- 应用弹窗封装
- 网络请求封装
- 数据持久化存储封装
- 核心基类封装
- 核心控件封装
- 线程池封装
- 启动流程设计封装
- 应用生命周期设计封装
APP模块依赖结构图
main模块
main模块是系统中最细化的部分，也就是底层策略，它是整个系统的初始点。在整个系统中除了操作系统不会再有其他模块依赖它。它的任务是创建所有的工厂类、策略类以及其他的全局配置，并最终将系统的控制权交给最高抽象层的代码来处理。
业务模块
登陆、工作台、消息、个人中心、订单属于业务模块。在设计上它们属于高层模块，负责创建指定与业务相关的高层策略，在系统中它们应该是最稳定的那一部分。具体的实现上最好不要牵扯到太多的细节，实现可以通过依赖反转（DIP）和稳定抽象原则（SAP）来构建插件注入到系统中（插件式的架构在系统中构建起了防火墙，避免系统中某一部分出现问题会导致其他不相关部分出现问题）
业务模块一般由业务实体（业务逻辑、业务数据）、业务用例、外层环境组成。业务实体是系统中最重要的部分，它是帮助公司赚钱或者省钱的那部分代码，我们不希望其他不相关的代码的改动，会导致它出现问题。它应该是系统中最独立，复用性最高的代码，其他底层概念的实现应该以插件的形式接入到系统中，以此来保证业务逻辑的纯净。业务用例描述某些特定条件下的业务逻辑，规定和限制业务规则。外层环境来描述和适配当前的环境，与具体的系统相关。
插件模块
识别出系统中独立，复用性最强的部分。根据依赖倒置原则（DIP）构建插件，使得底层细节插件，反向依赖高层策略组件，使得依赖关系往更稳定的方向进行（稳定抽象原则），构建更稳定的系统。