这是我参与「第四届青训营 」笔记创作活动的的第9天







架构设计是为了解决特定领域不同发展阶段的业务问题
不同领域的架构有明显的技术差异,但也有很多相似性
架构不仅面临技术挑战,还要应对组织业务膨胀的嫡增
移动端需要利用有限的设备资源设计符合小屏幕的架构

视图:XML
控制器:Activity中设置点击事件
模型接口:更新UI
数据和视图并没有完全解耦,控制器和视图耦合在一起,Activity会膨胀

数据和视图完全解耦了,控制回路太庞大。


面向切片编程思想。




不同架构手段的共同目标是高内聚低耦合
找到适合业务场景的架构而不是炫技滥用
一个复杂的系统是多种架构模型的组合体
做一个信息流产品,可以无限刷的列表
首先,需要实现一个列表,支持上下滑动
然后,每次滑动,都需要请求服务端数据
接着,列表的每一项都需要响应点击操作

产品功能开始变多,需要拆分模块
首先,需要支持图文内容的组合混排显示
接着,需要引入账号体系,用户注册登录然后,用户可以收藏感兴趣的内容并分享
…
继续,场景越来越多,拆分网络和多线程

业务场景变多,需要拆分业务
首先,支持用户发布文章,并给予奖励
接着,视频这个重要的内容也需要支持
然后,不同业务之间越做越大需要拆分
继续,拆分出视频业务,架构自成体系
继续,拆分出中台业务,供多业务使用


不同业务和模块混合,需要解耦
首先,需要约定模块可以对外提供的能力
接着,模块之间需要遵循相同的调用方式
然后,旧的模块需要按照相同标准来改造
…
继续,使用方不应该直接依赖于实现方



业务变得更加内聚,需要灵活插拔
首先,扫一扫等能力不是所有场景都需要
接着,视频的子能力可以拆解后按需使用
然后,越来越多的业务想动态化发布产物
继续,动态化发布引入很多问题需要调优




用户规模和团队稳定,历史包袱重
首先,经过前期快速发展已经积累了大量历史包袱
接着,需要深入了解业务才能设计出更合理的架构
然后,很多改动牵一发动全局,代码被迫变得更差
…
继续,新旧技术栈共存,版本依赖冲突,冗余代码



人们相互甩锅
代码混乱无序

架构随业务发展由简单变得复杂是规律
没必要最初用复杂架构来解决简单问题
需要用规范持续重构来对抗代码的腐朽
定义问题 → 确定架构 → 方案落地 → 结果复盘
架构的问题是盘根错节的,将所有问题放在一起,就有轻重缓急之分,就有类别之分
区分问题的类别,就能在一定的边界内,匹配上对应的人来解决问题
挑战、问题、手段这些经常混为一谈,哪些是挑战?哪些是问题?那些是手段?
其实这些都是一回事,就是矛盾,只是不同场景下,矛盾所在的层级不同

Ctrl c + v
