积分需求开发总结

tip

总结需要精练，简洁，直接，且在普通用户的角度上思考，是否看得懂。
如有不对，恳请指点。

积分需求-事件风暴

结合现有DDD框架设计积分系统。

背景说明

积分需求是平台或者商城比较通用的需求，结合自己之前的开发经验，现对目前DDD开发模式做一个总结输出。
大部分的积分功能都是为激活保留客户服务的。
然积分简单的话功能，就送积分和用积分。
但是如何把这两个部分做的解耦，且每个模块也是相互独立，且业务化，就需要抽象模块化的思考了。

设计思路

1. 价值流（需求目的）

核心目的：构建积分系统，激活社区用户

2. 提取用户故事（第一步要干啥）

• 2.1 查看规则，看积分是什么，积分如何获取，如何使用等

• 2.2 明确是什么，如何获取之后，就去尝试获取积分

• 2.3 获取积分的方法：任务形式（读取任务列表）

• 2.4 完成任务获取积分（积分变更）

• 2.5 获取完积分后需要查看积分变化（积分总数和详情）

3. 提前业务服务

从用户故事中提前业务对象，规则（关联任务，做什么任务获取多少积分的规则），任务（读取，算积分），积分（变更，查看）

4. 结合业务服务画uml

• 4.1 时序图

• 4.2 类图

实现方法

1. 工厂模式

2. 基于接口开发（参考option模式）

趟过的坑

抓主要流程

caution

一定要抓主要矛盾，比如这里流程就是任务算积分，再变更积分，至于不同的任务如何算积分完全是业务本身的事情，主干不用关心。

先设计后代码

caution

设计需要给出需求的业务流（从最开始干啥到最终用户得到了啥）
设计需要给出详细的时序图和类图（只有这一步作完后才可以去写代码，否则写的代码极有可能是if else 满天飞的屎山代码） 设计要通盘考虑，不要完全照猫画虎，给出详细的设计，并且设计完后的收益是啥，解决了啥问题，都要想清楚

业务流程化,代码事件抽象化

caution

什么什么化，都是套路，只有自己去写代码总结的时候才有深刻感悟，不断总结，才能得到自己的设计模式，否则都是书本的设计模式，别人的设计模式