后端程序分层的问题

你可以在 service 发一个写入的 event ，cache 的部分加一个 hook 来处理 event ，这样逻辑上就解耦了

还在研究这玩意儿呢，是我穿越了么

@zhudan 又被嘲笑了. sad

代码分层是为了对人更友好，目前的情况可以试着对大模型更友好一些，减少分层，让模型一次尽量拿全信息。

强一致性可以考虑事务，将缓存放到事务中，优雅点的的写法，可以参考 spring 的 transaction event ，使用 event 。
非强一致性，这样写也不会有多大问题，大不了查询的时候再查一遍，除非你业务能达到缓存穿透的并发量，不然两者没啥差别。

ps：求学有什么可嘲笑，啥都不懂就能用好大模型了吗

我这面是直接在 repository 层方法里处理了。缓存（ redis/caffine ）+DB （ JPA/mybatis ）。repository 监控指标也底层改了下，监测到有 sql 执行才会记录指标。
开发人员多的情况下，一个 model 层对应的缓存处理只在 repository 层方便所有人通用。如果是在 service ，代码多起来很难看，很难通用。如果是 springCache 那种，注解散在各个 service 中，实际开发会很难受。
service 就处理业务，别让他参合 DB 层的东西了，不管是 DB 的缓存还是直接取 DB 的数据。
我也考虑过，再多一个缓存层，后来想来想去觉得没必要就没搞。