一个 App 随着业务的增长，必然会出现现有的架构无法满足承载当前业务的情况。
特别是初创公司，这一点可能会更加的明显。公司刚成立的时候，为了快速发展，迭代非常快速，每次迭代往往是新功能、新业务的增加。这时候代码框架的好坏一般处于次要的地位。但是随着这样的发展，到了一定的阶段后，迭代的速度会慢下来。这其中很大一部分原因是因为各种逻辑、各种业务实现由于缺少梳理，慢慢的变成了一个大泥球，会发现有补不完的漏洞、填不完的坑，这时候业务增长就会倒逼架构上的调整。
目前公司也遇到了这样的问题，所以在调研的同时整理了一些架构方面的资料，希望可以给这方面有需要的人提供一些思路。
那如何拆分是比较好的拆分方式呢？
我们可以把独立性强的业务抽离出来，从而独立开发、优化以及维护，公共的部分可由架构团队统一管理和维护。
抽象、隔离、解耦各个业务线，以什么方式进行？
我们采取了插件方式把各条业务线独立开来。
作为一个优秀的技术团队永远要权衡做或不做，多做或少做。
那么插件和模块有什么区别？我认为二者最大的区别在于独立性。插件是可以独立开发，独立发布，独立运行的，而模块则必须依赖主工程的环境。具备独立性的插件可以很好的隔离跨团队之间的依赖，彼此独立开发，按照各自的节奏发布版本。
整个模式升级基本上经历了这样几个阶段：
- 代码独立，先从形式上解耦
- 独立代码工程化，为独立运行打下基础
- 梳理依赖关系，独立工程可编译
- 放弃源码依赖，提速集成编译
对于大的架构重构，其实我们一直很谨慎的。我们的原则是将重构融合在每次迭代中，逐步优化代码的结构。
整个架构的核心思想是面向接口编程和依赖注入使各个模块之间实现解耦，然后通过横向角色划分与纵向层级划分的方式约定各个模块之间的关系，再通过接口分层的方式，明确具体模块在不同层级上需要实现的功能，最后 AOP 横向切入的方式，去实现测试、调试工具、插桩等行为。
如何拯救「大泥球」架构？人人车Android客户端架构演进实录
当快速迭代的架构不足以支撑长期的持续性开发时，系统重构迫在眉睫。但对于大中型项目来说，事情并不是一句「重构」就能解决的。从何时何地开始做，怎么做，都需要好好考量。
每种子业务，都应该有边界，有了边界才有所谓的内聚性，才能区分外部使用者和内部实现者。
数据边界的宗旨是隔离外部原始数据和内部业务数据，在数据结构的维度实现边界和职责划分，以此来缓冲外部污染数据对内部业务逻辑的冲击力。
组件化相比于单一工程优势是显而易见的：
加快编译速度，提高开发效率；
自由选择开发框架（MVC /MVP / MVVM /）；
方便做单元测试；
代码架构更加清晰，降低项目的维护难度；
适合于团队开发；
为公司节省了经营成本；
这几个项目有一些的可操作性是比较强的，可以马上在自己的产品中实施起来。
从这几个项目中也可以看出一些主要的思想，梳理业务逻辑，化整为零，只有把整个项目拆分成合适大小的模块，再去考虑如何串起这些模块，那么，自然而然架构就出来了。
