189 8069 5689
猿设计同样是一个原创系列文章，帮助你从一个只是具备一些技术名词的小白猿人，开始掌握一些行业内通用的设计系统方法，提高你需求挖掘、需求分析、系统分析和设计的能力，完成属于你的能力聚变，设计系列完成，带你撸一个真电商出来，更多精彩内容，敬请大家关注公主号猿人工厂，点击猿人养成获取！
说起价格二字，你一定会觉得好奇，价格有什么好讲的啊，之前促销的设计不是已经讲过了吗（看下图），都已经知道价格是由促销系统来控制的了。
确实如此，比如用户访问商品详情页面，商品详情获取商品信息后，根据类目、SPU、SKU等信息，从让促销系统去计算，从而获取商品的优惠以及价格。而这个价格的调控，我们是通过商品上的商品“供货价”来做为价格基数，和促销系统发生联系来调控的。从这个层面上来讲，似乎价格确实是由促销系统来决定。
但是，在下这个结论之前，我们来先考虑以下几个事情。用户的哪些行为会和价格发生关系？嗯，商品详情页。已经说过了，用户需要看到。购物车页面，用户要看到价格，才知道买什么，买多少吧。结算页面，要付款了，不知道价格，不是坑人吗？提交订单，下单不需要后端的价格计算吗？页面提交的价格就一定正确吗？
我们可以通过画图的方式，来梳理下上述几个页面的流程，商品详情页面已经画过了，暂时略过。
从上面的图中可以很清晰的看出来，用户会很多场景会看见商品的价格。而这些场景并不相同，对应的业务也不相同。但是，有一个共性——用户需要价格。那么如果某一天，价格系统的计算逻辑需要发生了变化，而其它系统也必然发生变化，从而导致计算逻辑的改变。
我们可以看一下，商品详情页需要修改,结算页需要修改，购物车需要修改，订单需要修改……而这些修改将带来大量的资源成本和时间成本。很多系统在考虑设计的时候（比如一些开源的，还有某些机构的），并没有考虑单独考虑价格这个问题，从而决定了demo永远只能是demo……
所以，价格应该独立于商品、类目、促销等等模块来说，是势在必行的一个事情。我们可以看一下，价格独立设计之后带来的影响。
看见了吧?所有的和钱相关的事情，由价格系统/模块处理，其余的系统/模块只用关注价格系统/模块的接口就好了。而价格计算的逻辑，由价格系统/模块去完成即可。价格相关的逻辑变化，是价格系统/模块内部的事情，不要再麻烦其它人了，而其它人也不必再关注这个事情了。无论从运营上，以及维护的人力和时间成本来看，这样无疑是一个更优解。
接下来，我们就聊一聊价格系统/模块，本身有什么职责以及和促销之间又有什么联系呢。价格系统/模块，独立之后，自然就是为大家提供价格服务了，因为所有的人都等着他的回答xxx,多少钱。这个问法自然有所不同了。我们大致可以考虑为下面的用例。
从具体的场景分析，价格计算的设计可以考虑为两个方面的事情，第一是根据单个类目ID、SKUID获取价格，第二是根据类目ID、SKUID批量获取价格。从程序的精度和实时性的要求上来讲，订单价格计算和结算页价格计算对价格的要求更高，而详情和购物车，相对低一些，在设计时可以分开考虑。
也许你觉得价格计算比较简单，不值得区别对待，那么接下来，我们要来聊一个有趣的事情。说有3个SKU分别为A，B，C，供货价（商品原价）均为4块。现在A，B，C，一起购买参加了一个满10块减2块的活动，一起购买需要10块钱。问，A，B，C的实际售价是多少？
嗯，好嘛，2块钱的优惠，每个sku优惠了0.6666元，那四舍五入，每个3.34元，这样一来，总价就是10.02元了，说好的十块钱呢，奸商吗？那每个sku都是3.33元，这样一来，总价就是9.99元了，说好的十块呢？少的那一分研发出吗？这个问题看过来，猿人工厂君教你破法。
先用除法快速计算出平均优惠数（小数点后两位四舍五入），然后根据sku种类累加优惠总数，如果累加总数等于优惠总数，那么每个sku的价格为sku原价-平均优惠数，如果累加总数等于优惠总数，则需要随机一个sku来补足优惠差额。
正是因为类似的事情还有很多，所以价格计算需要独立出来单独设计，这还仅仅是业务上的一个划分，至于为了保证性能的一些改造，等我们业务层面的设计完成之后，在后续的实现中，再给大家讲解。
我建了一个技术群，群里有很多高手，加小编微信，备注：学习。带你见识更多的高手，帮你快速成长。