•
Coder

模块设计之消息模块

新手上路，小心撞车..

前言

#消息模块# 这是我刚入职时所接触的第一个模块，也算是比较大的模块了。这个模块的业务是负责整个项目所有的消息出入口，包含短信发送，APP推送，邮件发送以及前后端人员站内消息。当时设计的时候需求架构比较简单而且时间紧迫(π__π)，没有从根本理清业务和功能后期存在的扩展。因此，这篇文章是记录当时架构的思路和需要改善的地方。

开发周期 (10day)

  • 库表设计
  • 接口整理和整合设计(短信&友盟&邮件等)
  • 代码编写

业务流程图

表

  • 消息记录表, 主要负责消息出入口记录
  • 事件触发表, 主要对消息进行控制，例如: 触发订单变更推送到用户/运营人员 and so on
  • 消息状态表, 主要负责消息发送的状态，包含定时发送，撤销发送 and so on

图

当前业务流程图

类流程图

当前类流程图

如图，此模式主要是利用工厂模式, 提供多种消息通道实例，由不同的消息通道对自身通道消息进行处理，类似于把西瓜，牛肉，白菜等送入不同的工厂进行加工，但是又由食品质量控制中心对其进行记录和检验。

优点: 后期便于扩展更多的通道模式
缺点: 各个模式是靠类型区别的，不便于进行细节化处理(例如，对某部分APP推送进行定制化，进入某个Activity等细节化定制)

进一步优化类流程图

使用Route进行更细节的定制化处理
更多实战，推荐

图

当前类流程图

囧，单看图可能细分不出两者的差别，附上一段代码实例

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
// 路由规则初始化，用于定义匹配规则
NoticeRouter router = new NoticeRouter();
route.rule()
    .noticeType(Notice.SMS)
    // ... 更多细节规则匹配
    .handler(smsHandler)
    .end()
    .rule()
    .noticeType(Notice.EMail)
    // ... 更多细节规则匹配
    .handler(emailHandler)
    .end()

// 将通知实体通知路由处理
router.route(message)

总结

  • 充分考虑后期业务需求 (就算非必须的业务需求)

    不要妄想需求是恒久不变的，需求=小三，扩展=真爱

,
分享到