Feathers + Sequelize 的后台模块怎么拼

Feathers.js 之所以适合内部平台，一个重要原因就是 service 边界天生比较清楚。但真到项目做大以后，大家又会遇到另一个问题：一个后台模块到底应该由哪些文件拼起来，放在什么层级最稳？

这个问题如果不先想清楚，后面常见的结果就是 Hook 到处飞、Sequelize 查询到处写。

一个后台领域最好围绕一个 service 收口

比如文章管理模块，通常会围绕 posts service 组织，再把校验、权限、列表查询、状态流转这些行为挂在它周边。这样团队读代码时能先找到服务入口，再往外看依赖。

如果 service 只是薄薄一层转发，而大量逻辑散在随机工具文件里，可维护性反而会下降。

Sequelize 模型负责数据表达，不负责后台流程

模型应该回答的是表结构、关联关系和基础查询能力，而不是“发布文章时顺手写操作日志”“删除分类时顺带清缓存”这种流程问题。

把后台流程压进 model hook 看似方便，实际会让领域动作很难追踪。

Hook、service、schema 各自回答不同问题

我更喜欢这样分：

• schema 或 DTO 定义输入输出契约
• Hook 处理横切关注点和边界收口
• service 负责编排当前模块的核心业务动作

三层如果职责清楚，哪怕文件多一点，也比“所有逻辑塞进 service class”健康得多。

后台模块组合最怕共享黑盒工具

很多项目做到一半会冒出一些“万能列表 helper”“万能查询 builder”。它们短期提效，长期却可能把不同模块的真实差异抹平，最后一改就连锁影响很多 service。

可复用当然重要，但前提是边界真的相似。

小结

Feathers + Sequelize 适合做后台，不是因为它们自带神奇架构，而是因为只要 service、model、Hook 各守边界，模块会天然比较清晰。组织方式收好了，后续扩展就轻松很多。