前期的需求沟通分析、中期的代码设计实现、后期的系统上线维护等。
1、需求分析
积分是一种常见的营销手段，很多产品都会通过它来促进消费、增加用户粘性，比如淘宝积分、信用卡积分、商场消费积分等等。
具备产品思维，并不是完全的“技术控”
Google 很多产品的初期设计都是工程师来完成的，在产品发展壮大到一定程度的时候，才会引入产品经理的角色。
作为技术人，我该怎么做产品设计呢？首先，一定不要自己一个人闷头想。
- 一方面，这样做很难想全面。
- 另一方面，从零开始设计也比较浪费时间。
爱因斯坦说过，“创造的一大秘诀是要懂得如何隐藏你的来源”。
比如淘宝，看看它们是如何设计积分系统的，然后借鉴到我们的产品中。
我们还要充分了解自己公司的产品，将借鉴来的东西糅合在我们自己的产品中，并做适当的微创新。
积分系统无外乎就两个大的功能点，一个是赚取积分，另一个是消费积分。
赚取积分功能包括积分赚取渠道，比如下订单、每日签到、评论等；还包括积分兑换规则，比如订单金额与积分的兑换比例，每日签到赠送多少积分等。
消费积分功能包括积分消费渠道，比如抵扣订单金额、兑换优惠券、积分换购、参与活动扣积分等；还包括积分兑换规则，比如多少积分可以换算成抵扣订单的多少金额，一张优惠券需要多少积分来兑换等等。
还有一些业务细节需要考虑，比如积分的有效期问题。
通过产品的线框图、用户用例（user case ）或者叫用户故事（user story）来细化业务流程，挖掘一些比较细节的、不容易想到的功能点。
用户在获取积分的时候，会告知积分的有效期；用户在使用积分的时候，会优先使用快过期的积分；
用户在查询积分明细的时候，会显示积分的有效期和状态（是否过期）；
用户在查询总可用积分的时候，会排除掉过期的积分。
1.1 积分赚取和兑换规则
积分的赚取渠道包括：下订单、每日签到、评论等。
积分兑换规则可以是比较通用的。比如，签到送 10 积分。
比如，按照订单总金额的 10% 兑换成积分，也就是 100 块钱的订单可以积累 10 积分。
积分兑换规则也可以是比较细化的。
对于积分的有效期，我们可以根据不同渠道，设置不同的有效期。积分到期之后会作废；在消费积分的时候，优先使用快到期的积分。
1.2 积分消费和兑换规则
积分的消费渠道包括：抵扣订单金额、兑换优惠券、积分换购、参与活动扣积分等。
我们可以根据不同的消费渠道，设置不同的积分兑换规则。
比如，积分换算成消费抵扣金额的比例是 10%，也就是 10 积分可以抵扣 1 块钱；100 积分可以兑换 15 块钱的优惠券等。
1.3 积分及其明细查询
查询用户的总积分，以及赚取积分和消费积分的历史记录。
2 系统设计
面向对象设计聚焦在代码层面（主要是针对类）
系统设计就是聚焦在架构层面（主要是针对模块）
2.1 合理地将功能划分到不同模块
合理地划分代码可以实现代码的高内聚、低耦合，类与类之间的交互简单清晰，代码整体结构一目了然
系统设计实际上就是将合适的功能放到合适的模块中。合理地划分模块也可以做到模块层面的高内聚、低耦合，架构整洁清晰
我们有下面三种模块划分方法。
第一种划分方式
积分赚取渠道及兑换规则、消费渠道及兑换规则的管理和维护（增删改查），不划分到积分系统中，而是放到更上层的营销系统中。
这样积分系统就会变得非常简单，只需要负责增加积分、减少积分、查询积分、查询积分明细等这几个工作。
比如，用户通过下订单赚取积分。订单系统通过异步发送消息或者同步调用接口的方式，告知营销系统订单交易成功。
营销系统根据拿到的订单信息，查询订单对应的积分兑换规则（兑换比例、有效期等），计算得到订单可兑换的积分数量
然后调用积分系统的接口给用户增加积分。
第二种划分方式
积分赚取渠道及兑换规则、消费渠道及兑换规则的管理和维护，分散在各个相关业务系统中，比如订单系统、评论系统、签到系统、换购商城、优惠券系统等
还是刚刚那个下订单赚取积分的例子，在这种情况下，用户下订单成功之后，订单系统根据商品对应的积分兑换比例，计算所能兑换的积分数量，然后直接调用积分系统给用户增加积分。
第三种划分方式
所有的功能都划分到积分系统中，包括积分赚取渠道及兑换规则、消费渠道及兑换规则的管理和维护。
用户下订单成功之后，订单系统直接告知积分系统订单交易成功，积分系统根据订单信息查询积分兑换规则，给用户增加积分。
怎么判断哪种模块划分合理呢？
我们可以反过来通过看它是否符合高内聚、低耦合特性来判断。
如果一个功能的修改或添加，经常要跨团队、跨项目、跨系统才能完成，那说明模块划分的不够合理，职责不够清晰，耦合过于严重。
为了避免业务知识的耦合，让下层系统更加通用
一般来讲，我们不希望下层系统（也就是被调用的系统）包含太多上层系统（也就是调用系统）的业务信息，但是，可以接受上层系统包含下层系统的业务信息。
比如，订单系统、优惠券系统、换购商城等作为调用积分系统的上层系统，可以包含一些积分相关的业务信息。
反过来，积分系统中最好不要包含太多跟订单、优惠券、换购等相关的信息。
我们更倾向于第一种和第二种模块划分方式。但是，不管选择这两种中的哪一种，积分系统所负责的工作是一样的，只包含积分的增、减、查询，以及积分明细的记录和查询。
2.2 设计模块与模块之间的交互关系
系统职责划分好之后，接下来就是设计系统之间的交互，也就是确定有哪些系统跟积分系统之间有交互以及如何进行交互。
比较常见的系统之间的交互方式有两种
一种是同步接口调用，
另一种是利用消息中间件异步调用。
第一种方式简单直接，第二种方式的解耦效果更好。
用户下订单成功之后，订单系统推送一条消息到消息中间件，营销系统订阅订单成功消息，触发执行相应的积分兑换逻辑。
这样订单系统就跟营销系统完全解耦，订单系统不需要知道任何跟积分相关的逻辑，而营销系统也不需要直接跟订单系统交互。
上下层系统之间的调用倾向于通过同步接口
同层之间的调用倾向于异步消息调用
2.3 设计模块的接口、数据库、业务模型
业务系统本身的设计无外乎有这样三方面的工作要做：
接口设计、数据库设计和业务模型设计。
网友评论