本文首发于公众号：移动开发那些事拒绝“炫技”式开发：好的架构，一定要让新人看得懂
1 背景
最近接手了一份同事编写的业务库，其逻辑之复杂令人咋舌：原本可以通过简单的继承与组合实现的功能，被硬生生拆解成了极其晦涩的多层架构。不仅可读性极差，后续修改更是举步维艰。
这段经历让我深度反思终端架构的核心价值：优秀的架构究竟是“化繁为简”，还是“化简为繁”？ 基于此，本文将围绕三大核心问题展开探讨，拆解好架构的设计逻辑与落地路径：
- 评判指标：什么样的架构才算好架构？
- 底层原则：设计好架构需要遵循哪些“军规”？
- 实操路径：普通开发者如何一步步进化为架构师？
2 什么是好架构？
2.1 架构的本质
软件架构的本质绝非追求极致的技术实现，而是在理解业务的基础上，通过设计在交付速度与系统稳定性之间取得平衡。
对于客户端开发（Android/iOS）而言，无论是经典的 MVC、MVP，还是流行的 MVVM、MVI，其核心目标都是一致的：实现 UI、业务逻辑与数据的解耦。
2.2 好架构的三个维度
脱离业务谈架构，再“高大上”都是自嗨。判断架构优劣，核心看这三个指标：
- 适配业务：解决核心矛盾
- 易于维护：降低长期成本
- 持续演进：适配未来增长
2.2.1 适配业务：解决核心矛盾
架构的生命力，在于与业务场景的精准匹配。脱离业务阶段的架构设计，再精巧都是“自嗨”。
- 初创期：业务核心是“快速验证”，单体架构、KISS 原则（Keep It Simple, Stupid）就是好架构。
- 成熟期：面对高并发或跨团队协作，能支撑插件化、组件化、自动化的架构才是好架构。
警惕： 不要为了炫技引入不匹配的复杂度。如果
MVC就能清晰解决的业务，强行套用MVVM反而是负担。
2.2.2 易于维护：降低长期成本
好架构能让开发者“少踩坑”。它的代码结构清晰、模块边界明确，能让开发者少踩坑、少返工，降低长期研发成本。具体可体现为三点：
- 新人友好：新成员接手时，阅读代码能快速梳理出业务主线。
- 排查无忧：具备清晰的日志追踪和异常捕获体系，定位问题无需翻遍整个工程。
- 简单胜于复杂：如果一个接口能搞定的事，非要写 5 个类、3 层继承，那就是典型的过度设计。
2.2.3 持续演进：适配未来增长
业务是动态变化的。好架构绝非“一劳永逸”的静态设计，而是能平滑扩展的“生机体”，核心在于低耦合 与可替换：。
- 低耦合：模块间边界清晰，新增功能时像“搭积木”，无需大动手术。
- 可替换：如果哪天想把存储层从 SQLite 换成 Room，或者把网络库从 OkHttp 换成 Ktor，不应触动核心业务逻辑。
3 好的架构遵循哪些原则？
万变不离其宗，优秀的架构往往植根于经典的 SOLID 原则，其中这三点在业务开发中尤为关键：
3.1 单一职责原则 (SRP)
核心定义：“一个类/模块，只负责一件事。” 这是最基础也最难坚持的原则。它能有效避免“上帝类”的出现，降低代码改动时的风险。
3.2 开闭原则 (OCP)
核心定义：“对扩展开放，对修改关闭。” 当业务需求变化时，我们应该通过增加代码而不是修改旧代码来实现，这是架构具备“可演进性”的核心保障：
- 反例（硬编码）：在支付逻辑里用
if-else硬编码各种支付方式（微信、支付宝、银行卡）。 - 正例（接口抽象）：抽象出
IPayment接口，每增加一种支付方式只需实现一个新类。
3.3 依赖倒置原则 (DIP)
核心定义：“高层不依赖底层，两者皆依赖抽象。” 这是解耦的终极武器。业务逻辑不应该知道数据是从本地数据库读的，还是从网络接口取的。
- 落地建议：通过接口（Interface）或抽象类定义通信契约。模块间通过“协议”说话，而不是直接“握手”。
4 如何打磨一份好的架构设计？
不要幻想一步登天，好的架构是“长出来”的。
4.1 理清业务，绘制地图：
拿到需求后，先别敲代码。画出核心流程图、状态机或时序图。分清哪些是核心业务逻辑，哪些是外部支撑工具。
4.2 合理分层，定义边界：
客户端开发中，最通用的分层方式是“三层模型”，核心是明确各层职责，避免层间耦合：
- 表现层：负责 UI 展示与用户交互，仅处理界面相关逻辑（如控件刷新、点击事件），不掺杂业务逻辑。
- 业务层：系统的“灵魂”，负责核心业务规则（如订单状态流转、支付逻辑校验），不依赖 UI 层与具体数据源，仅依赖抽象接口。
- 数据层：负责数据获取与存储，包括网络请求、数据库操作、缓存管理等，对外提供统一的数据访问接口，屏蔽底层实现细节。
4.3 小步快跑，持续重构：
架构优化需“适度”，切勿追求“一步到位”。初期可采用简单架构快速落地，后续根据业务痛点逐步重构：
当发现某个类臃肿到难以维护、某段逻辑被反复拷贝（冗余），或新增功能时需要大量修改原有代码，就是重构的信号。警惕“为了解耦而解耦”——过度拆分模块会导致架构碎片化，反而提升维护成本。
5 结语：架构的本质是“平衡”
世界上没有“完美的架构”，只有“最适合当前业务”的架构。设计架构时，需牢记三个核心认知：
- 不要过度设计：如果你只需要显示一个 "Hello World"，就别去搞什么 Clean Architecture。
- 演进胜于预设：架构需要随业务痛点而进化，而不是在开工前预设一个巨无霸框架。
- KISS 永远滴神：最好的代码是那种让新人一眼就能看懂、且符合常识的代码。
最后想说：架构师的价值，不在于能设计出多么复杂的框架，而在于能洞察业务本质，将混乱的逻辑梳理得井然有序，用最简单的方式解决复杂问题——让团队少走弯路，让系统持续健康演进。
