拯救祭天的程序员——事件溯源模式

一、事前

你相信吗？曾经有一段日子，我几乎没接到过合格的产品需求。

开局几句话，技术全靠猜。

总是以为简单的需求

曾经，我从产品那里接到过这么一个需求:

对系统的用户进行分级，不同级别的用户有不同的福利。

依然如常，无图无文档，只是这么一句话。我知道，需求一句话，分析五日功嘛。为了项目能持续发展，我只好自己分析自己搞了。

从业务上看，目前的用户对象尚无等级一说，我们先为用户对象加上个级别属性。又因为不同的用户等级，可享受到不同的福利。比如：达到 3 级的用户，可以享受购物 9.5 折优惠，物流费用全免，客服快速回复等。

所以，我做出设计如下:

首先，我把每个等级用户该享受的福利放到一个列表里。这个用来供前端展示用户当前可享受到的福利。

然后，在每一项福利中，我去设定一个可享受此福利的最低级别。只有用户的级别超过这个最低级别的时候，才可以享受到此项福利。比如，支付优惠 9.5 折，我只需要在支付服务中打包个支付权利 9.5 折这种东西，然后设定个最低级别即可。

这事儿看着是如此简单，所以，实现方案也没什么特殊的。当用户每次升级的时候，我只需要更新用户级别即可。

这个时候，需求比较初级，要求也不高。在满足升级条件后，需要用户主动点击升级。同时，再填写一些相关信息，申请一些专属的福利就可以了。

好，设计，开发，上线一条龙走起来！

需求变成坑

过了一阵子，我们的运营们勇于探索，勤于开拓，去搞了一堆资源互换回来。当我听说此事时，心里已经预感不妙了。

果然，没两天，我们的产品高高兴兴地通知我，由于兄弟团队愿意和我们的项目进行合作，因此用户的福利将得到极大的丰富，那些更加丰富的福利全都由兄弟团队提供。

所以，请我简单的搞一下，对接上这些合作方，进一步提升我们系统的粘性。

如常，依然没有任何文档，我依然只能自己分析。

现在，根据我丰富的被折腾经验，我知道开始有坑了。当我对接合作方接口的时候，他们都需要我传入一些特定的用户标识过去，可以让双方共享用户。

需求开始复杂了，不过庆幸的是，我改改代码就可以了，还好还好，我松了口气……

好，设计，开发，上线一条龙走起