Rails 的优势是约定清晰，很多功能可以很快落到 controller、model 和 view 里。但项目变大之后，真正影响可维护性的不是文件夹有多少，而是业务边界是否清楚。
我通常会先让 controller 保持薄一些：接收参数、调用明确的业务入口、处理响应。model 负责和数据强相关的校验、状态流转、scope，以及那些离开数据上下文就不好理解的领域行为。
当一个流程跨越多个模型，或者包含外部服务、事务、后台任务这些协作时，我会把它提成 service object。这个对象不需要为了抽象而抽象，它只要把一条业务路径命名清楚，让调用者知道“我要完成什么”。
后台任务适合处理不需要同步返回的事情，比如发送通知、生成报表、同步第三方数据。这里最重要的是幂等性：任务可能重试，队列可能重复投递，所以任务执行多次也应该保持结果可控。
一个 Rails 后端是否稳定，很多时候取决于边界是不是朴素。controller 不偷偷做业务，model 不承担整个世界，service 不变成万能脚本，job 不假设自己永远只跑一次。