北京
“2019年12月我发表《Just Eat模块化iOS架构》时，模块化在iOS开发中还算个新概念。”时隔六年，作者带着明显的兴奋重新审视了这套一度引领团队走向单体仓库、有向无环图与严格依赖规则的架构。当初的出发点很明确：把多个国家的应用收拢到单一平台，用康威定律指导拆分，而不是单纯为了编译并行。
那篇文章描述的架构是一个有向无环模块图，分为领域、核心和共享三大类，明令禁止对等模块之间相互依赖。到2025年底，CocoaPods已被Swift Package Manager彻底替代，当年试探性倡导的单体仓库成了行业标配，团队规模大幅扩张，模块数量差不多翻了一倍。然而，架构图的基本形状和核心依赖规则几乎纹丝未动。
一些设计被时间证明极其耐用。依赖图必须无环——模块间的依赖永远单向流动，绝不允许直接或间接的循环。功能模块之间不打交道，凡是需要共享的东西都被提取到更低层级的模块里，这有效阻止了长期迭代后容易滋生的横向耦合。每个模块只暴露一个窄而稳定的门面，内部可以用MVVM、TCA或任何团队偏好的模式，只要躲在门面后面就行。最被津津乐道的是每个模块都自带一个独立的演示应用，它成为推动良好接口设计、充当活文档并提供极快本地反馈闭环的利器。
真正让团队重新打开讨论的裂缝，来自一个看似不起眼的UI组件——CountdownTimer。它是在自家设计库之上构建的倒计时控件，并不属于JET设计系统，却同时被“结账”和“餐厅”两个领域模块使用。按2019年的模型，每个模块非此即彼地归属于三大组别之一，但这个横跨两个领域模块的UI组件找不到合适的安身之处，暴露出多年来悄悄累积的概念模糊。
2026年的刷新并非要推翻2019年的架构，而更像一次词汇的精炼与规则的延伸，专门覆盖原模型未定义的灰色地带。好架构的真正力量或许正在于此：外壳经得起六年冲击，内里的调整只需一缕轻巧的更新。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
