业务抽象笔记

抽象意味着什么？

把一个需求看成一类需求，把一个产品看成一筐产品

• 维护成本低

怎么看待低维护或者无维护成本？真正的抽象业务能力应该是使端对同类业务扩展无感知，也就意味着对产品来说新的同业务产品在技术层面上面的改造应该是无或者是很小程度上在上游的适配。

• 高可扩

业务抽象能力能够使的新增的业务需求在已有设计中可以做到很高的可扩展性，稍微增加一些业务抽象逻辑即可适配。

• 高开发成本(首次)

如果对一个业务需求都去做一次抽象，毋庸置疑会增加首次的开发成本，但随之带来的是高可扩和低维护。这是一个开发在日常业务中需要自己衡量的。

• 高嘲讽

这个主要是在业务开发进行抽象的时候带来的一些问题，一般都是因为在首次开发的时候需要额外的开发成本。经常会听到一些反面的声音，会怀疑业务上拓展的能力以及额外的开发成本所带来的反感。因为业务的抽象是会带来额外的理解成本的。

抽象的妥协

每个业务开发程序员，都需要去带着这样的抽象思考去看待每一个需求，把一个需求看成一类需求，把一个产品看成一筐产品。因为即使无法从真正业务上做到抽象，也可以在代码层面做一层抽象。这种抽象在我日常开发中显而易见，也正是因为这样的先见之明，在后续的一些业务对接上占据了很大的优势。上面说到过，抽象肯定会带来额外的开发成本，量力而行。一些业务可能并不明确或者抽象依赖对后端接口的设计。这些情况下，都是可以做首次抽象妥协的，先做一个版本试一下。把抽象作为下一次的迭代任务有时候也是一种明智之举。

其他的思考

• 局部抽象

对于一些业务链路特别长，综合考虑后觉得整条线要打通的话涉及部分之多可能会带来产品的延期，那么就可以尽量做到局部的抽象，尤其是一些链路特别长的业务需求，局部抽象能力可以让业务具有相对较高的可扩展性。下面举一个具体例子 - 搭售超级会员：

超级会员这个业务比较复杂，复杂的原因是其涉及模块较多，链路较长。分别从菜单(导购模块)到篮子(篮子模块)，再到结账页(BK模块)，这样一条长的链路如果在首次开发的时候直接做到对具体业务的抽象是非常困难的，其中涉及不光是客户端的程序设计，也包括后端接口的抽象设计。因此当时折中的方案是做到下游(篮子，结账也)的局部抽象，放弃导购作为上游业务端的营销业务的抽象。具体的程序代码不在此赘述，简单的描述一下篮子和结账页。

在开发结束后，篮子作为一个食物缓存的容器，原本只保存一些食物和一些活动信息。那么对于超级会员产品被接入到篮子中，如果理解成一种搭售产品被加入到篮子中，那么搭售产品的就应该和食物平等的存在。而篮子也不需要去关注具体的搭售产品是什么，对于篮子来说超级会员的篮子加购其实就是一个具体id的加入并透传到结账页(BK模块)，结账页再把该List<id>作为参数传入接口。可以设想一下，当搭售产品业务扩展后，我可能都不需要去篮子模块和BK模块做相应的代码修改。