我们这样设计消息中心，解决了业务反复折腾的顽疾

消息系统大概是业务系统里最“精神分裂”的模块。它一边要稳定存储——像日记一样记下发生过的事。另一边又要灵活展示——像实时播报内容没了得知道变“失效”。代码的复杂度往往就从这里开始爆炸——我们把“是什么”Data和“怎么做”Behavior混在了一锅里炖。今天就聊聊我们如何通过三次关键的“分离手术”让消息中心从混乱走向清晰。这是系列的第三篇我们进入最核心的战场模型如何被使用。这是《面向对象开发实践之消息中心设计》系列的第三篇。在前两篇中第一篇解决的是 “为什么要这样设计一个消息中心”从面向对象的视角拆解需求、边界与职责第二篇聚焦在 消息模型本身从最小消息单元出发一步步引入分类、业务关联、富文本、图片与布局。从这一篇开始我们正式进入”模型如何被使用“的阶段。本篇重点讨论三个问题消息类型如何建模而不失控消息如何被渲染消息行为跳转、点击、实时数据如何与模型解耦消息类型的正确职责划分在前面的模型中我们已经有javaenum MessageBizType {COMMENT,LIKE,MENTION,VIOLATION,LOTTERY}但 enum 只是标识真正的行为不应该写在枚举里常见的做法是javapublic interface MessageHandler {MessageBizType bizType();Message buildMessage(MessageCreateContext context);}每种消息类型只关心三件事我处理哪种 bizType如何构建 Message 模型需要哪些业务数据MessageCreateContext为什么需要一个“创建上下文”上面提到MessageHandler 构建消息时传入的是一个 MessageCreateContext但没有刻意第一时间展开。这是因为Context 不是消息系统的起点而是模型稳定之后的自然产物。最原始的做法参数直传不可拓展在最初阶段很多系统的消息创建代码大概是这样的javacreateCommentMessage(Long receiverId, Long commentId, String commentText);这种方式的问题不在于”能不能用“而在于参数列表会随着业务不断膨胀不同消息类型需要的参数完全不同调用方必须知道消息内部需要什么业务代码被迫了解消息系统的细节。第一次抽象统一参数对象下一步的常见演进是javaclass MessageCreateDTO {Long receiverId;Long bizId;String extra;}这一步解决了“参数过多”的问题但新的问题随之出现字段语义不清晰extra 是什么不同消息类型依赖同一个 DTODTO 会被不断污染它只是“换了一种方式堆字段”。Context 的真正职责描述“一次消息创建的事实”在面向对象的语义中Context 并不是 DTO。DTO 用来传数据Context 用来描述一次行为发生时的完整上下文。MessageCreateContext 的设计目标是只描述“发生了什么”不关心“如何生成消息”不绑定具体消息类型javapublic interface MessageCreateContext {Long getTargetUserId();MessageBizType getBizType();Long getBizId();}这是一个极度克制的最小接口。向下演进类型化 Context而不是字段膨胀当不同消息类型需要更多消息时正确的演进方向不是给接口加方法而是针对具体业务定义具体的 Context 实现。例如评论消息创建javapublic class CommentMessageContext implements MessageCreateContext {private final Long targetUserId;private final Long commentId;private final String commentSummary;// getters}违规消息创建javapublic class ViolationMessageContext implements MessageCreateContext {private final Long targetUserId;private final Long postId;private final String ruleName;// getters}这样做带来的好处是每个 Context 都是强语义的Handler 只依赖它需要的 Context不存在“通用但混乱”的字段Context 与 Handler 的关系边界一个非常重要的约束是MessageHandler 只信任 Context不反向依赖业务对象。javapublic interface MessageHandlerC extends MessageCreateContext {MessageBizType bizType();Message buildMessage(C context);}这意味着Context 是 Handler 的唯一输入消息系统与业务系统形成“单向依赖”Context 是“防腐层”不是万能对象最后需要特别强调的是Context 不应该承载业务逻辑、访问数据库、变成一个 All-In-One 对象Context 应该稳定、只读、可测试它的价值在于把一次消息创建封装成一个可理解、可传递、可演进的事实对象。示例一评论消息CommentMessageHandler1. 使用场景A 评论了 B 的动态B 收到一条评论通知2. 关键设计点消息不持有 Comment 对象只保存 commentId文本支持「部分跳转」3. Handler 实现javapublic class CommentMessageHandler implements MessageHandlerCommentMessageCreateContext {Overridepublic MessageBizType bizType() {return MessageBizType.COMMENT;}Overridepublic Message buildMessage(CommentMessageCreateContext ctx) {return Message.builder().userId(ctx.getTargetUserId()).category(MessageCategory.INTERACTION).bizType(MessageBizType.COMMENT).bizId(ctx.getBizId()).layout(MessageLayout.IMAGE_TITLE_TEXT).content(buildContent(ctx)).sendTime(LocalDateTime.now()).build();}private RichTextContent buildContent(CommentMessageCreateContext ctx) {return RichTextContent.of(RichTextSegment.text(你的动态收到了新的评论),RichTextSegment.link(ctx.getCommentSummary(),MessageJumpConfig.route(/comment/detail, Map.of(id, ctx.getBizId()))));}}注意Handler 不关心“怎么存”只负责构建领域模型示例二违规通知ViolationMessageHandler违规通知的特点文本固定多处可点击跳转生命周期长javapublic class ViolationMessageHandler implements MessageHandlerViolationMessageCreateContext {Overridepublic MessageBizType bizType() {return MessageBizType.VIOLATION;}Overridepublic Message buildMessage(ViolationMessageCreateContext ctx) {return Message.builder().userId(ctx.getTargetUserId()).category(MessageCategory.SYSTEM).bizType(MessageBizType.VIOLATION).bizId(ctx.getBizId()).layout(MessageLayout.IMAGE_TITLE_TEXT).title(内容审核未通过).content(buildContent()).sendTime(LocalDateTime.now()).build();}private RichTextContent buildContent() {return RichTextContent.of(RichTextSegment.text(您发表的内容因违反《),RichTextSegment.link(社区规范, MessageJumpConfig.url(https://example.com/rule)),RichTextSegment.text(》未能通过审核请),RichTextSegment.link(修改后重新发布, MessageJumpConfig.route(/post/edit)));}}这里可以看到第二篇中“结构化富文本”的价值。困境静态存储 vs 动态业务在第二篇中我们刻意将 Message 设计得很轻只存了 bizType 和 bizId而没有存具体的业务文案比如“张三评论了你”。这是为了应对一个经典的业务难题数据一致性与时效性。请看这个场景上午 10:00用户 A 评论了用户 B“你的文章写得真烂”。上午 10:01用户 B 还没来得及看消息列表。上午 10:05用户 A 删除了这条评论或者评论被系统审核删除了。上午 10:10用户 B 打开消息中心。如果我们在创建消息时直接把文案写死在数据库里用户 B 就会看到一条“幽灵消息”——点击进去却提示“内容不存在”体验极差。但如果是“系统发放优惠券”我们又希望即使活动结束了那条通知依然保留当时的快照。结论很明显不同类型的消息对“实时性”的要求是完全不同的。快照型Snapshot系统通知、活动中奖。内容生成即固定。引用型Reference评论、点赞、。内容依赖业务主体的当前状态。策略模式渲染器的多态设计面向对象的精髓在于多态。我们不需要在 MessageService 里写一堆 if (type COMMENT) { ... } else if (type SYSTEM) { ... }而是应该引入渲染器Renderer概念。1. 定义渲染接口渲染器的职责非常单一把冰冷的数据库实体DO翻译成用户可读的视图对象VO。javapublic interface MessageRenderer {// 策略判定这个渲染器支持哪种业务类型boolean support(MessageBizType bizType);// 核心行为输入存储实体输出展示视图MessageVO render(MessageDO message, Long viewerUserId);}2. 实现引用型渲染以评论为例对于评论消息渲染器需要实时查询业务服务并处理“失效”逻辑。javaComponentpublic class CommentReplyRenderer implements MessageRenderer {Autowiredprivate CommentService commentService; // 依赖业务服务Overridepublic boolean support(MessageBizType bizType) {return MessageBizType.COMMENT_REPLY bizType;}Overridepublic MessageVO render(MessageDO message, Long viewerUserId) {// 1. 实时回查业务数据CommentDTO comment commentService.findById(message.getBizId());// 2. 兜底处理如果业务数据没了被删、审核不通过if (comment null || comment.isDeleted()) {return MessageVO.builder().layout(MessageLayout.TEXT_ONLY).content(RichText.of(该评论已被删除)) // 降级展示.action(Action.NONE) // 禁止跳转.build();}// 3. 正常组装利用第二篇定义的 RichText 和 Layoutreturn MessageVO.builder().layout(MessageLayout.IMAGE_TITLE_TEXT).title(comment.getUserName() 回复了你).image(comment.getUserAvatar()).content(RichText.fromSegments(Segment.text(回复内容),Segment.link(comment.getSummary(), JumpConfig.toComment(comment.getId())))).build();}}3. 实现快照型渲染以系统通知为例对于系统通知内容直接存在消息体的 content (JSON) 字段中直接反序列化即可无需查库。javaComponentpublic class SystemNoticeRenderer implements MessageRenderer {// ... support 方法省略Overridepublic MessageVO render(MessageDO message, Long viewerUserId) {// 直接从 DO 中通过 JSON 反序列化出 RichTextContentRichTextContent content JsonUtils.toObj(message.getContent(), RichTextContent.class);return MessageVO.builder().layout(MessageLayout.TITLE_TEXT).title(message.getTitle()).content(content).build();}}这一设计的收益是巨大的隔离变化新增“订单发货通知”只需要新增一个 OrderRenderer 类无需修改主流程代码。降级保护业务数据删除或服务异常时渲染器可以独立决定显示“内容已删除”还是直接隐藏。总结从数据到能力的跃迁回顾这三篇文章的演进路径第一篇我们把“消息”从依附于业务的字符串变成了一个独立的领域概念。第二篇我们通过设计 RichText 和 Layout让模型拥有了结构化表达能力不再依赖写死的前端代码。第三篇本篇我们引入了 Message、Handler和Renderer让静态数据拥有了动态适应业务变化的能力。细心的你可能发现我们目前的所有逻辑都是同步的。 如果这时候有一篇爆款文章瞬间涌入 10 万条评论我们的数据库能不能扛得住渲染器在列表页进行 N1 次 RPC 调用查询业务数据接口会不会超时面向对象解决了逻辑的复杂度但架构设计解决的是规模的复杂度。后面我们可以尝试从“规模”的角度继续拆解消息中心如何应对高并发、去重、防刷与异步化。原文链接https://juejin.cn/post/7586901995429560329