本文首发于公众平台:腐烂的橘子
开发代码时,工程师经常有做抽象的冲动,其实架构师也如此,早期架构设计中,经常会出现不必要的抽象。
这也是大家口中常说的“盖楼”行为。
抽象是代码设计中的一个必要手段,它可以尽量使代码变的通用,避免过多的业务定制化代码。
然而在高速迭代的互联网业务中,业务往往探索的方向变化大,迭代快,进行多层架构往往是得不偿失的,相比之下更好的办法是进行阶段性重构。
多层抽象与阶段性重构的区别在于:
- 多层抽象是在业务模式完全确定之前所做的架构抽象
- 阶段性重构,是在业务模式稳定且明确有浪费代码的情况下,针对重点领域所做的重构,这是在架构目标内的抽象
相比之下,阶段性重构的目标更加清晰,更适合快速发展的互联网环境。
比如你想做一个商家中台来抽象实体商家和数字发行商,一旦深入到细节,你会发现其中的差异会非常大:
- 实体商家的核心需求有商家入驻店铺、创建店铺运营等,而数字发行商的核心需求有签约内容、发布、运营和退出
- 实体商家角色的运营需求有上下架爆款,打造私域、运营大促、转化分析、进销存管理等,而数字发行商的运营需求则是上下架、营销内容、创作粉丝运营、周边生态建设等
上面的每个需求在实际操作时所需要的界面也大不相同,以上下架为例,在两个角色中是完全不同的:
- 对于售卖实体商品的商家来说,上下架的动作是商品详情的描写、图片文字和视频上传、类目选择、确定价格和内容等
- 而对于数字商品则是:元数据的编写、从第三方获取数字商品的图片和文字信息、信息质量的验证、从供应商指定的文件传输渠道获取原文件、对原文件的编码转码、加密原文件、CDN 的分发等
如果没有了解细节就进行架构抽象,那么最终的效率只能停留在假设阶段,你必须要意识到的是抽象会提升系统的复杂度,削弱系统的迭代效率和稳定性,因此没有目标驱动和数据支撑的架构抽象是不可取的。
因此最佳的做法是先满足业务需求,在模式稳定后进行阶段性重构。
满足业务需求时,有一个很重要的观念是:先做好隔离再去做抽象。
隔离和抽象的区别是什么呢?
- 隔离是将两个实体的任务分开,有各自独立的封装和实现
- 抽象是在两个实体之上,抽象出第三个实体,共享部分任务的实现
抽象这件事可以等后面再做,由于引入了第三个实体会增加系统的复杂度,因此,最好在业务稳定之后进行。而隔离是当务之急,尽量减少实体之间的耦合度,为后面的抽象奠定基础。
比如上面提到的上下架需求,主要的实体有商家、供应链、链接、类目、商品、元数据、原文件等,主要操作有类目选择属性、验证商品、风控、获取文件、内容加密等,这些实体和操作都可以中台化或者 Fass 化。
不用过分抽象,但必须要隔离。
注:文章来源于极客时间课程:郭东白的架构课