深度解构“沙拉食刻”钱包账户模块
作为一名产品经理，竞品调研是必不可少的能力之一。通过竞品调研，不仅可以学习其他产品的优秀设计，还可以锻炼自己的分析能力。
最近，我正在设计一套适用于非银行金融企业的钱包账户模块。为此，我研究了一些不同行业中带有“钱包”功能的产品，并选择了我日常使用的“沙拉时刻”进行解构。
一、沙拉时刻简介
“沙拉时刻”是一款无人自助售餐机产品，用户可以通过手机选餐下单，然后到对应的自助机凭借订单取餐。其模式就跟自助贩卖机、自助咖啡机和自助橙汁机等产品类似。由于本文不涉及商业分析，因此不再对其模式进行过多介绍。
二、钱包账户模式
要解构“沙拉时刻”账户模块，首先需要研究其账户结构以及账户数据结构是什么模式。
2.1 账户结构
从小程序端可以看到，该产品有“钱包余额”（后文称为“沙拉钱包”）和“沙拉豆”两个钱包账户。点击“沙拉钱包”后，可以看到该钱包包含“总余额”，以及“充值余额”和“赠送消费金”（后文简称“赠金”）。
该沙拉钱包的账户结构有两种设计模式：
- 模式一，在后端表数据设计中，采用母子结构，总余额作为母账户，充值金额和赠金作为子账户。
- 模式二，在后端表数据不设计总余额，只设计充值金额和赠金两个平级账户。用户在小程序中看到的总余额，由前端将上述两个账户余额相加计算得出。
从余额明细点进去看到的流水可以确定，该产品采用的是账户结构模式一，因为流水记录的是总余额的流水，而不是充值金额和赠金的流水。
2.2 账户数据模式
基于账户结构模式一进一步分析，账户的数据模式还可分为“单账户数据多字段模式”和“多账户数据模式”，分别如下：
单账户数据多字段模式
好处是设计简单，维护方便，数据量相对较少。坏处是当业务量蓬勃发展后，无法精准统计某段时间内用户使用的“赠金”金额。
多账户数据模式
好处是每个账户都可以清晰记录流水，各自进行对账，扩展性和复用性也高。
由于在“沙拉时刻”小程序中没有找到充值金额账户和赠金账户的流水记录，因此，假定该产品采用的是“单账户数据多字段”模式。
2.3 解构“账户管理”表
至此，我们可以解构出该产品背后的简单“账户管理”表。
若心细如丝的友人，或许仍记得前文所提及的“沙拉豆”账户。该账户的主要作用在于用户运营，以增强用户粘性。
从系统角度出发，可以单独开发一个积分模块。但实质上，它可被视作账户模块下的一个“积分账户”。为使其与这种设计相兼容，我们可对“账户管理”表进行如下修改：
- 新增一个字段“账户类型名称”，用于标识每个用户名下的不同类型账户。
- 将沙拉钱包账户 ID 抽象为公用字段，改名为账户 ID。不同类型的账户可采用不同的 ID 规则。
通过这种方式，后续设计的入账、流水、统计等功能无论是用于“沙拉钱包”还是“沙拉豆积分”都可以共用。如此，便能实现账户体系的统一性和灵活性。
三、钱包账户流水
3.1 流水的分类
从余额流水明细中可以看出，该产品将流水分为充值、消费、退款和其他几种类型。
如果进一步细分，其实还可以增加充值退款和提现这两种类型，不过由于该产品在小程序端不开放充值退款和提现功能，因此可能没有设计这两种流水类型。
分类流水的好处如下
- 方便财务和运营管理，每种分类都代表了不同的交易类型，使用户能够更清晰地了解资金的流入和流出情况。
- 公司经营维度，分类流水提供了详细的收入和支出数据，便于进行分析。可以了解充值和消费的趋势，找出高消费项或异常支出，从而进行必要的调整和优化。
- 提升用户体验和透明度，分类流水记录用户可以更清楚地了解自己的交易历史，包括充值、消费、退款和提现等情况。
3.2 流水的组成
我们继续看每一条流水明细，分别由以下几部分组成
- A.流水名称：表示这一笔流水的业务场景。
- B.流水交易时间：指这笔流水的发生时间。
- C.流水交易金额：代表本次交易的发生金额
- D.余额：这里的余额其实指的是这个钱包账户发生本次交易之后剩下多少余额。流水记录发生交易后的余额提供了透明度、可追溯性（方便事后校验和排查问题），其次在某些情况下，流水记录中的余额信息可能对税务申报和合规性要求有用。
3.3 解构“账户流水”表
按照上述流水明细组成，结合以下思路“什么时间，哪个用户的哪个账户，发生了什么交易，交易金额是多少，以及交易钱包账户余额是多少”，不难解构出以下账户流水表。
可以看到上表还有一个创建人和备注，其实是用于记录特殊情况流水的发生背景和操作人，方便事后业务核实。
其次上文曾提及过，“总余额”其实包含了“充值金额”和“赠金”，“单账户数据模式”不方便精准统计“充值金额”和“赠金”的消费情况，因为他们没有各自单独记录的流水。
因此我们可以在“总余额”流水里面，再增加记录多2个字段，分别是“充值金交易金额”和“赠金交易金额”，以满足精准统计的需求。
3.4 流水的统计
为了方便用户查看每个月在“沙拉钱包”中的充值和消费金额，余额明细页面还设计了按月筛选和按月统计的功能。
程序实现该功能有两种方法：第一种是在进入页面后实时进行汇总计算；另一种是事先将统计数据持久化到数据库中。
如果采用第一种方法，需要让技术人员考虑后期用户数量增加和数据量增大的问题，评估请求量和计算量，以确保服务的稳定性。
本次解构到此结束。如果有更多感兴趣的小伙伴，我们将继续解构入账、充值、交易等功能。
版权声明
本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！
