标签：cas 产品 两种 实战 积分兑换 多少 例子 不同 中间件
借鉴类似产品
技术人也要有产品思维
要懂得借鉴：爱因斯坦：“创造的一大秘诀是要懂得如何隐藏你的来源”
两大功能：赚取积分;消费积分
通过产品的线框图、用户用例（user case ）或者叫用户故事（user story）来细化业务流程，挖掘一些比较细节的、不容易想到的功能点。
通过以上方法总结最终功能需求
积分赚取和兑换规则
积分的赚取渠道包括：下订单、每日签到、评论等。积分兑换规则可以是比较通用的。
比如，签到送 10 积分。再比如，按照订单总金额的 10% 兑换成积分，也就是 100 块钱的订单可以积累 10 积分。除此之外，积分兑换规则也可以是比较细化的。比如，不同的店铺、不同的商品，可以设置不同的积分兑换比例。
对于积分的有效期，我们可以根据不同渠道，设置不同的有效期。积分到期之后会作废；在消费积分的时候，优先使用快到期的积分。
积分消费和兑换规则
积分的消费渠道包括：抵扣订单金额、兑换优惠券、积分换购、参与活动扣积分等。
我们可以根据不同的消费渠道，设置不同的积分兑换规则。比如，积分换算成消费抵扣金额的比例是 10%，也就是 10 积分可以抵扣 1 块钱；100 积分可以兑换 15 块钱的优惠券等。
积分及其明细查询
查询用户的总积分，以及赚取积分和消费积分的历史记录。
合理地将功能划分到不同模块
第一种划分方式是：积分赚取渠道及兑换规则、消费渠道及兑换规则的管理和维护（增删改查），不划分到积分系统中，而是放到更上层的营销系统中。这样积分系统就会变得非常简单，只需要负责增加积分、减少积分、查询积分、查询积分明细等这几个工作。
第二种划分方式是：积分赚取渠道及兑换规则、消费渠道及兑换规则的管理和维护，分散在各个相关业务系统中，比如订单系统、评论系统、签到系统、换购商城、优惠券系统等。还是刚刚那个下订单赚取积分的例子，在这种情况下，用户下订单成功之后，订单系统根据商品对应的积分兑换比例，计算所能兑换的积分数量，然后直接调用积分系统给用户增加积分。
第三种划分方式是：所有的功能都划分到积分系统中，包括积分赚取渠道及兑换规则、消费渠道及兑换规则的管理和维护。还是同样的例子，用户下订单成功之后，订单系统直接告知积分系统订单交易成功，积分系统根据订单信息查询积分兑换规则，给用户增加积分。
怎么判断哪种模块划分合理呢？
是否符合高内聚、低耦合特性
如果一个功能的修改或添加，经常要跨团队、跨项目、跨系统才能完成，那说明模块划分的不够合理，职责不够清晰，耦合过于严重。
让下层系统更加通用
一般来讲，不希望下层系统（也就是被调用的系统）包含太多上层系统（也就是调用系统）的业务信息，但是，可以接受上层系统包含下层系统的业务信息。比如，订单系统、优惠券系统、换购商城等作为调用积分系统的上层系统，可以包含一些积分相关的业务信息。但是，反过来，积分系统中最好不要包含太多跟订单、优惠券、换购等相关的信息。
所以，综合考虑，更倾向于第一种和第二种模块划分方式。但是，不管选择这两种中的哪一种，积分系统所负责的工作是一样的，只包含积分的增、减、查询，以及积分明细的记录和查询。
设计模块与模块之间的交互关系
确定有哪些系统跟积分系统之间有交互以及如何进行交互。
常见的系统之间的交互方式：一种是同步接口调用，另一种是利用消息中间件异步调用。
第一种方式简单直接，第二种方式的解耦效果更好。
比如，用户下订单成功之后，订单系统推送一条消息到消息中间件，营销系统订阅订单成功消息，触发执行相应的积分兑换逻辑。这样订单系统就跟营销系统完全解耦，订单系统不需要知道任何跟积分相关的逻辑，而营销系统也不需要直接跟订单系统交互。
上下层系统之间的调用倾向于通过同步接口，同层之间的调用倾向于异步消息调用。
比如，营销系统和积分系统是上下层关系，它们之间就比较推荐使用同步接口调用。
设计模块的接口、数据库、业务模型
模块本身如何来设计
标签：cas 产品 两种 实战 积分兑换 多少 例子 不同 中间件
原文地址：https://www.cnblogs.com/wod-Y/p/12776509.html
