券后价复杂根源和解法
券后价领域划分不清楚
券后价在电商系统中是个很奇怪的存在
无论是按商品领域还是营销领域划分，它都不合适归类到这两者中间。结果就是券后价是个很不理想的拆分逻辑。
券后价可以理解是商品的价格属性，这个属性是由营销来计算控制。领域划分可以理解为商品领域，营销做计算！核心承接方为营销，只有营销才知道哪些优惠适用哪些商品，哪些人拥有优惠。
所以券后价是营销承接商品领域的算价能力。
在营销领域，券后价到底是工具活动领域还是券领域也是模糊不清
第一感觉是，券领域。要知道，有些券是没发到手上，也要显示券后价，所以，券后价称之为优惠活动价更为准确。
而目前的逻辑是，券也是活动的生成的。本质上是记录用户与能参与活动的凭证，所以，将券后价服务划分到营销工具领域更合适。
券后价是不确定的价格
确定的价格
券后价是指一个商品通过优惠工具，显示购买时预计的一个价格。
所以，券后价准确与否一直是个很难界定的需求。
大多数场景下，券后价一定是用户购买时的价格一致，否则就是价格欺诈！
不确定的价格
而有些场景下，券后价只是一个参考价，如首件优惠、折扣价。用户可以买到这个价格的商品，但这个价格是有一定条件的。在显示价格的时候，需要特殊处理。
影响价格的并不只是优惠，还有商品本身的售卖价格也会调整。就导致一个价格由多个团队决定。
券后价规则复杂
各种大类的叠加互斥，平行规则的叠加互斥，优先级计算和各种显示规则等。规则多的需要用文档维护，早期没有产品主导的系统混乱不堪。
计算券后价所需要的条件
计算券后价，首先是三个主要主体-用户、商品、优惠。
计算的主要参数，用户id，商品id列表
- 找出用户拥有的优惠
- 跟据商品列表查询商品的价格等信息
- 建立商品与优惠的关系
- 计算价格
找出用户所拥有的优惠
用户找优惠券
一个用户能够拥有的只有券、余额、积分、会员、省钱卡等这类拥有用户属性的权益。
而在计算券后价时，是不会在价格中体现出余额、积分、会员等这些用户资产。
计算券后价时，只会拥有平台发给用户的券，外加平台给商品的降价工具影响价格。
那么就可以从用户获得券来切入。
在公司平台里，用户获得券一定是在建立的活动之上，活动投放会有区域。而每个用户在不同门店，可能参与的活动不一样，那么在投放侧，是可以精准备投放活动到门店。而用户只需要关心当前门店拥有哪些活动。或者在这个门店，门店是否拥有能力发券等。
如果公司平台的建营销权益工具只有指定门店，那么用户一定只需要关注在当前门店是否领取过券或者可以参与哪些权益活动。
这里权益活动包含领券活动和促销价活动。
商品也不应该有区域之分，这个商品能够在哪个门店卖，哪些门店有活动等，这里一定是有某种联系才能使整个系统较为合理的运转
按上图逻辑来说，这个用户与门店、商品、营销工具的联系就非常简单了。
用户查询营销工具的范围就可以通过所在门店找到对应的权益工具。而建工具最简单的办法就是跟据圈的门店建门店与活动的关系，这层关系就是用来查询用户的权益工具的索引。实现方式可以从简单的数据建表，到redis建key，甚至redis用map等都可以作为性能优化的手段，这一块就是体现真正技术实力的时候了。
那些圈选区域，排除区域，甚至黑名单门店，歇业门店不参与等活动规则全部让门店线做了。
最为关键的是，如何将这块数据流转起来，设计模型是最为重要的。
到这里，查询用户所拥有的优惠就变成了单表查询。
查询的时候，再过滤掉一些优惠的自身规则，如状态、过期时间等。
领域建模
- 商品
- 优惠工具
- 用户
- 门店
营销领域，能影响商品展示价格的只有优惠（优惠价、优惠券）。余额和换购不会影响价格展示，只在购物车和结算页时，进一步对全部商品作价格减免。
能影响有没有优惠的只有用户与门店。用户是指有没有优惠券，门店是指优惠价有没有投放到这个门店。
商品找优惠，为什么是商品找优惠，而不是优惠找商品。在真实的券后价计算中，一个用户和所在的门店基本是不变的，而变动的只有商品。所以，优惠不容易变，方便用来缓存。而前端页面每动一下商品就变了，对变动很大的参数常常用来作计算。这样就比较好的利用了各自的特性简化逻辑和提升性能。
领域模型基本信息
商品、用户、门店信息都非常简单，都有对应的业务线提供基本数据。优惠信息相对较多且乱，但如果用领域模型重新归类一下。领域模型不关心底层如何存储，只关心自身领域模型在创建的时候，由谁提供数据源。
优惠领域在创建的过程将要收集营销工具所有的信息，并归类好，将会是个很庞大的工程。
建立商品与优惠的关系
商品信息有了，优惠信息有了，这个商品适用于哪些优惠等，优惠叠加、互斥、优先级等，都需要在建立关系这一步将全部归类清楚，只有在这一步归类好了。后面计算就是简单的加减法了。下面展开讲一下如何建立商品与优惠的关系。
商品选优惠
- 优惠价工具&商品关系：优惠价工具是由商品建的索引查询出来的，在查询的时候，就可以将此关系建立。建立关系时，优惠工具的状态、库存、圈品等规则依次枚举判断，这个关系是个实体对象在内存中。
- 优惠券工具&商品关系：优惠券适用于这个商品一般分2种关系。一种单品券，一对一关系。一种多品券，一对多关系。
商品选优惠是指先把能建的关系建好，后面在考虑优先、互斥、排除等。这层关系一直都在，如果有排除，只是将商品与优惠的关系改个状态，如失效掉之类的。这样，在券列表中为什么不能使用这个优惠直接拿这个关系状态就好了。
优惠叠加
产品定义：单品券与多品券、余额、购物卡可叠加。在实现过程中有了【商品&单品优惠关系】不影响建立【商品&多品优惠关系】，同理也不影响其他关系的建立。
产品定义：单品促销价与多品促销价、新人价等价格工具互斥，只享受优惠力度最大的。如果有了【商品&单品促销关系】，再有满减促销价更大的优惠来时，跟据优惠大小失效掉原来的单品促销价关系。
优惠优先级
先排序，后失效关系。
- 按产品逻辑定义。价格优先级是促销价格>单品券>多品券>余额>购物卡。在关系优先级排序后，要将排在后面的关系失效掉。
- 按产品逻辑定义。同类促销价不同类型的降价工具有优先级：单品定价>新人价>特价>单品价>满减价>折扣价。在关系优先级排序后，要将排在后面的关系失效掉。
优惠互斥
同类互斥规则：排序完后，就会有一个商品同时作用于多个同类优惠的情况，对于这种情况，产品定义优惠大的优先。在排序后，失效掉排在后面的关系。
不同类互斥：就失效掉优先级低的。
整个关系的建立就是一个核心，这样逻辑非常明显的体现出整个规则适用过程。这个时候领域模型就能大行其道，简化逻辑判断。
用户自己选择优惠顺序（券后价无需要计算）
用户能选择的优惠只有多品券，在同类商品有多个多品券的排序中，增加一个最高优先级排序，即用户自己选择的优惠排最前。
计算价格
每个商品能够适用的优惠关系建立完后，计算价格就是一个非常简单的事了。越是简单的操作，越不容易出错。以售卖商品这个领域对象作为整个计算的聚合根模型，将这个商品的售卖价格属性、有效的券工具列表作为属性，做简单的减法。
- 找到这个商品有效的关系（自身属性）
- 将这个商品依次减价（自身方法）
当然还有一些特殊处理的逻辑减价，如折扣、首件优惠等，但本质上只是多了一种减价策略。
如券后价逻辑是这样清晰之后，再想想购物车逻辑，结算页逻辑。无非是在创建关系时，系统按规则建关系转变成可以由用户自己选择优惠，即用户手动改变规则建立商品与优惠的关系。
那些可用券列表，不可用券列表，不可用券原因，都是关系建立的结果。
在锁券时，逻辑将更简单，商品适用的关系已经有了，只需要将价格计算这一小步做成sdk就可以了。而计算价格这一步简直不要太简单。锁券真正关心的也就只有商品与优惠的库存还有没有，有就锁住库存，结束！
