架构每日一学 16 ：不要再做多层抽象了！

本文首发于公众平台：腐烂的橘子

开发代码时，工程师经常有做抽象的冲动，其实架构师也如此，早期架构设计中，经常会出现不必要的抽象。

这也是大家口中常说的“盖楼”行为。

抽象是代码设计中的一个必要手段，它可以尽量使代码变的通用，避免过多的业务定制化代码。

然而在高速迭代的互联网业务中，业务往往探索的方向变化大，迭代快，进行多层架构往往是得不偿失的，相比之下更好的办法是进行阶段性重构。

多层抽象与阶段性重构的区别在于：

• 多层抽象是在业务模式完全确定之前所做的架构抽象
• 阶段性重构，是在业务模式稳定且明确有浪费代码的情况下，针对重点领域所做的重构，这是在架构目标内的抽象

相比之下，阶段性重构的目标更加清晰，更适合快速发展的互联网环境。

比如你想做一个商家中台来抽象实体商家和数字发行商，一旦深入到细节，你会发现其中的差异会非常大：

• 实体商家的核心需求有商家入驻店铺、创建店铺运营等，而数字发行商的核心需求有签约内容、发布、运营和退出
• 实体商家角色的运营需求有上下架爆款，打造私域、运营大促、转化分析、进销存管理等，而数字发行商的运营需求则是上下架、营销内容、创作粉丝运营、周边生态建设等

上面的每个需求在实际操作时所需要的界面也大不相同，以上下架为例，在两个角色中是完全不同的：

• 对于售卖实体商品的商家来说，上下架的动作是商品详情的描写、图片文字和视频上传、类目选择、确定价格和内容等
• 而对于数字商品则是：元数据的编写、从第三方获取数字商品的图片和文字信息、信息质量的验证、从供应商指定的文件传输渠道获取原文件、对原文件的编码转码、加密原文件、CDN 的分发等

如果没有了解细节就进行架构抽象，那么最终的效率只能停留在假设阶段，你必须要意识到的是抽象会提升系统的复杂度，削弱系统的迭代效率和稳定性，因此没有目标驱动和数据支撑的架构抽象是不可取的。

因此最佳的做法是先满足业务需求，在模式稳定后进行阶段性重构。

满足业务需求时，有一个很重要的观念是：先做好隔离再去做抽象。

隔离和抽象的区别是什么呢？

• 隔离是将两个实体的任务分开，有各自独立的封装和实现
• 抽象是在两个实体之上，抽象出第三个实体，共享部分任务的实现

抽象这件事可以等后面再做，由于引入了第三个实体会增加系统的复杂度，因此，最好在业务稳定之后进行。而隔离是当务之急，尽量减少实体之间的耦合度，为后面的抽象奠定基础。

比如上面提到的上下架需求，主要的实体有商家、供应链、链接、类目、商品、元数据、原文件等，主要操作有类目选择属性、验证商品、风控、获取文件、内容加密等，这些实体和操作都可以中台化或者 Fass 化。

不用过分抽象，但必须要隔离。

注：文章来源于极客时间课程：郭东白的架构课