抽象就是在有一件事情出现的时候，稍微跳脱一点，用一种更加通用化，更加根本的方式解决问题。[1] —— 文章《抽象一步是理想和现实之间一座坚实的桥梁》
抽象的重要性
看完这篇文章后感慨颇多。在实际工作中，我们可能会遇到，要么严丝合缝顺着业务的描述来设计系统的，要么想太多太远，导致最终方案远离解决当前问题、实现周期长、上线后无人问津。
前者毫不抽象，贴着业务走，这样往往导致系统内的逻辑理不清绕不明白，经常重头来过。
后者过度抽象，最终远离业务，成了设计人员的曲高和寡、圈地自萌，最后一地零碎。
如何抽象思考
那么，该如何抽象呢，比如下面这个业务场景，该如何思考，如何把握好抽象的尺寸呢？
B to B 交易场景下，通常会有如下情况：
- 大多数客户（我所见的）还是习惯线下公对公转账的
- 存在一种现象：长期合作的客户，有时会将退款按下，留在卖方账上，用作下次采购付款使用 流程示意大概如下：
1. 先抽离出来
在了解全貌后，再抽离出来。 如果不抽离出来，不做任何抽象，我们可能将第二种情况与退款流程完全区分开，将其设计成一个独立的东西，而财务最终在系统上操作时，可能要记住两套完全不同的流程。
但是，我们所讨论的或思考的，仍然是在退款这个环节发生的事情，那是否仍然可以在退款的业务领域内，处理上面两种情况呢？
比如，在设计退款流程时（无论是仅退款还是售后退款），增加一个类似支付产品里常见的用户余额，将第二次情况也纳入退款流程。
如此，二者的区别不再是退不退款，而是都做退款处理，只是退款的去处不一样。顺着下来，用户下次采购付款要使用这笔预留款时，也增加一种类似余额付款的核销方式（不能叫支付，因为资金流实际发生在线下）。 这样设计，开发无需额外多做一套单独的流程，财务也无需记住多出来的操作。
2. 要抽象到什么程度
多想一步，抽象后要做到什么程度。
既然引出了余额的概念，那要不要做一整套余额的操作呢：充值、体现、支付等？如果要系统上做这一整套，财务上是否也需要调整呢，比如需不需要引入一些监管账户呢？
但这么想下去，是不是就复杂了，是不是成本也更高了，最后落地推动起来都阻力倍增？
那就又回到上述文章中，作者认为好的抽象，是仅抽象一步。
我认为最好的抽象是仅仅抽象一步。既不能不抽象也不能抽象超过一步，走到两步三步去。[2]
故我的想法是：仅在系统层面引入余额的概念，背后的实质仍然不变，财务上的处理仍然是预收账款或其他应退款。用户下次需付款时，在系统上则用余额支付的方式进行抵扣或核销，财务上则是将对应部分转为收入。
最后的话
另外，文中没有说的是，抽象思考的基石是在哪里，总不能无中生有，凭空捏造。从我看来，需要熟悉你所在行业里或其他行业里的通用做法，并在抛出行业或业务特性外，归纳出一些标准构件。怎么理解，比如库存系统和资金系统可能存在的相同点：
- 从财务上看，他们都属于企业的资产，所以有一般资产的属性
- 从模型上看，他们都有流水、余额、减少、增加、冻结这些概念
- 从流程上看，他们都受到上游实际场景驱动，比如销售采购或借款还款。
最后，想以这段话来勉励或告诫自己，能有大成就者，往往步步为营。不要抱着对现状的不满而妄想有一个理想国来让你一蹴而就达成心中所想。
他们的过人之处就是想到了最终的宏大目标，却把它们隐藏起来，而用大多数人能够接受的对于现实的一步改造开始，慢慢的积累动量，越改越快。[3]
[1][2][3]：《抽象一步是理想和现实之间一座坚实的桥梁》 来自 wangjianshuo.com