问题背景
前几天，和共事聊了这么一个场景：
交易系统，同时下单了商品 A & 商品 B，其中 A 商品买了 10 件，B 商品买了 20 件。正向订单曾经签收，订单流转至实现态，此时正向订单里的两个商品 A & B 都能够别离申请售后（逆向订单）。
然而为了保障不至于买了 10 件，退了 11 件这种状况产生。逆向订单创立的时候，须要晓得发动逆向的时候，正向订单曾经发动了几件商品的逆向，据此决定本次逆向最多能够退多少件。
问题
此时有两个计划：
- 正向订单的商品行上，冗余记录一个落库的“可申请逆向数量”字段。其保护的生命周期次要有两处：
a. 正向订单流转至完结态时，此字段被设置为正向订单的商品行所购买数量
b. 逆向订单创立时，此字段被扣减掉该次逆向订单申请的数量 - 不再长久化“累计申请逆向数量”字段，改为每次要用的时候，依据正向订单关联的逆向订单实时计算。
该选哪个
主观来说，在一个自营的交易系统里，逆向订单数据量不大的状况下，两种计划都能够。
- 第一个计划，复杂度次要是逆向订单以及正向订单的其余流程里须要多保护一个字段，因为每用都间接取值，所以性能比拟敌对。
- 第二个计划，因为每用每算，所以性能上会差一点。然而在订单数据量不大的前提下，仿佛也不是什么大问题。
这样看，仿佛应该选第一个计划才好。 然而实际上，此处我和共事磋商后，更倡议选第二个计划。
第一个计划，申请逆向自身的要害参数，依赖了正向订单，以及申请逆向时的多余参数，这会带来额定的了解老本。
因为须要确保设计性能需要时其余可能影响到“可申请逆向数量”的场景也必须保障本人能意识到这个字段的保护必要性和上下文。试想，咱们目前在做一个中台产品，又或者团队的外围人员有到职状况。- 正向订单完结须要填充“可申请逆向数量”这一常识，可能被到职人员带走而导致后续保护人员疏忽。- 2B 畛域，针对其余团队二次开发则更是如此，没有哪个二开团队能被动留神到这一具体的细节。第二个计划，因为申请逆向单流程每用每算，“可申请逆向数量”这个字段从头至尾，都被应用场景的代码持有和感知，因而，不论是外围人员有到职还是其余团队二次开发，均不会带来衍生的了解老本。因而，咱们更倡议这两种计划进行抉择时，抉择第二种计划。大数据量的性能降落，就留给查问阶段做性能优化吧。
衍生思考
计划决策，不存在不置可否的状况，A 计划能够，B 计划也能够的状况下，肯定存在一个强理由，决定了你此时就应该抉择 A 计划抑或是 B 计划。
这背地反馈的是你一整套计划考量的时候，到底什么才是外围问题，这个问题本人肯定要很分明，确定分明主次要矛盾，这远比问题的答案更要害。