诗歌社区模块设计

根据产品原型，初步划分出以下功能模块。

用户

数据：

• User：所有用户，并且设置一个所有人都默认关注的乐书小秘书

行为：CRUD

登录、注册

数据：

• Token：登录令牌，保存在Redis中

行为：

• 登录相关的对token的CRUD
• 第三方登录

邀请

数据：

• Invitation：用户(user_id reference User.id)与邀请码(invitationCode)之间的关系，用户被谁邀请(invited_by_user_id reference User.id)，最终整体形成了树型结构

行为：

• 邀请注册时创建用户，并且记录Invitation，并根据邀请树推荐好友让新用户关注
• 根据规则为用户创建自己的邀请码

待定业务规则：

• 是否强制用户默认关注乐书小秘书？
• 是否为所有用户创建邀请码？

关注

数据：

• Follow：单个单向的关注关系，最终整体形成了网结构

行为：CRUD

收藏、点赞、阅读记录

数据：

• Favorite
• Like/Vote
• ReadFootPrint：阅读记录

行为：

• CRUD

难点：

• 读写效率/计数查询效率–是否在数据库中设置字段保存计数
• 考虑引入消息队列，将写入赞、累加赞数量异步化，可以比较好地解决上述问题

待定业务规则：

• 收藏什么？
• 匿名点赞、增加阅读次数？采集的点赞、阅读数据在后续的推荐机制中会成为重要依据
• 只点赞还是可以点踩？取消赞
• 阅读次数是否重复计算

评论

使用简单线性回复，只是能@某人

数据：

• Comment

行为：

• CRUD

支付

仅用第三方支付

打赏

数据：

• Encourage：打赏记录
• AccountBalance：赏金余额

行为：

• CRUD

待定业务规则：

• 提现规则？是否真的需要在系统中实现这个功能？

诗歌

数据：

• Article

行为：

• CRUD

诗集

数据：

• Collection
• CollectionItem

行为：

• CRUD

难点：

• 诗集与诗是多对多关系，如果直接采用中间表，未来数据条数十分庞大，如果用连字符连id，查询性能极差

诗社

活动

推荐

需要一个管理平台，编辑设置推荐内容

数据：

• EditorRecommendation

行为：

• CRUD

管理员

参考喵书的AdminUser-Role-Permission模型

猜你喜欢

数据分析

消息

可能需要做成消息的事件包括但不限于以下类型：

• 成功邀请到用户
• 被关注
• 被收藏
• 被评论
• 在评论中被@
• 被打赏

如果需要实时显示小红点，可能需要消息服务器建立socket连接