目前架构一共分为四层, 从低到高依次是基础层,项目封装（如果不需要可能跳过这层）,业务层和宿主层。
宿主层
宿主层位于最上层, 主要作用是作为一个 App 壳, 将需要的模块组装成一个完整的 App, 这一层可以管理整个 App 的生命周期(比如 Application 的初始化和各种组件以及三方库的初始化)
业务层
业务层位于中层, 里面主要是根据业务需求和应用场景拆分过后的业务模块, 每个模块之间互不依赖, 但又可以相互交互, 比如一个商城 App 由 搜索, 订单, 购物车, 支付 等业务模块组成
Tips: 每个业务模块都可以拥有自己独有的 SDK 依赖和自己独有的 UI 资源 (如果是其他业务模块都可以通用的 SDK 依赖 和 UI 资源 就可以将它们抽离到基础SDK中)
业务模块的拆分
写业务之前先不要急着动手敲码, 应该先根据初期的产品需求到后期的运营规划结合起来清晰的梳理一下业务在未来可能会发生的发展, 确定业务之间的边界, 以及可能会发生的变化, 最后再确定下来真正需要拆分出来的业务模块再进行拆分
项目封装
项目封装主要是为了解决：同一个公司如果有多个项目，在处理 登录、用户数据、接口定义…上一般来说是相同的，所以在此对相同的模块进行一次封装。
基础层
基础层位于最底层, 里面又包括公共服务模块、 基础 SDK 模块, 核心基础业务模块 和 公共服务模块 主要为业务层的每个模块服务, 基础 SDK 模块 含有各种功能强大的团队自行封装的 SDK 以及第三方 SDK, 为整个平台的基础设施建设提供动力。个人认为，基础模块是一个可以脱离上层独立应用于各种app开发架构的模块，所以，基础模块应该是不包含各种业务逻辑处理，对网络、图片加载、SDK的封装不应该包含特定业务的处理
核心基础业务
核心基础业务 为 业务层 的每个业务模块提供一些与业务有关的基础服务, 比如在项目中以用户角色分为 2 个端口, 用户可以扮演多个角色, 但是在线上只能同时操作一个端口的业务, 这时每个端口都必须提供一个角色切换的功能, 以供用户随时在多个角色中切换, 这时在项目中就需要提供一个用于用户自由切换角色的管理类作为 核心基础业务 被这 2 个端口所依赖(类似 拉勾, Boss 直聘等 App 可以在招聘者和应聘者之间切换)
核心基础业务 的划分应该遵循是否为业务层大部分模块都需要的基础业务, 以及一些需要在各个业务模块之间交互的业务, 都可以划分为 核心基础业务
ARouter服务
ARouter服务:项目中使用ARouter进行模块之间的通信
####服务模块: 在model中声明Service,然后在自己的模块中实现这个 Service 接口, 再通过 ARouter API暴露实现类
业务模块:
通过 ARouter 的 API 拿到这个 Service 接口, 即可调用 Service 接口中声明的自定义方法, 这样就可以达到模块之间的交互