APP在用户少的时候怎么写都行，可一旦版本迭代几十次、团队从三人扩到十人，架构问题就藏不住了：改一个页面牵动全身、一处崩溃整个应用卡死、想拆开维护却无从下手。如何在设计之初就为将来的增长留出空间，是每个移动开发团队都要面对的课题。

起步阶段，单体架构其实是合理选择。所有功能写在一个工程里，开发简单、调试方便、发布直接，小团队用它能最快把产品推出去。问题在于，随着页面越来越多、参与的人越来越多，代码逐渐纠缠在一起，修改风险升高、发布互相等待，这时就到了该考虑拆分的节点。成都成华云创汇科科技有限公司的建议是：别急着拆，先让业务长到确实需要再动手。

模块化的思路，是把APP按业务边界拆成若干相对独立的功能模块，各自负责一块业务，通过约定好的接口与路由通信。好处很直接：某个模块出问题不至于拖垮全局，哪个模块迭代快就单独发版，不同的人也能并行开发互不阻塞。但代价同样真实，模块一多，依赖管理、版本协调、公共能力的复用的复杂度都会上升，没有相应的工程规范，拆分反而添乱。

所以架构演进的关键，不是一步到位上最时髦的方案，而是把握节奏。前期用单体快速验证，但代码内部按模块划清边界、约定清楚通信方式；当规模和组织真的撑不住时，再顺着已有边界逐步拆开。架构是为业务服务的，够用、能演进，就是好架构。