MemoFlow：为什么我没有直接采用 AI 的应用层解耦方案

问题不是“业务函数写得不够通用”

最初的前端实现里，ApplicationService 获取、转换数据之后，会顺手把结果写进 Store。留在应用里使用时看起来很顺手，但当时打算把 Application 层迁移进独立 package，才发现它实际上依赖了前端状态容器。

旧笔记中最值得保留的是这个判断：服务层承诺的是业务结果，却悄悄承担了界面状态更新。 独立包不应该为了返回一组业务数据就需要知道某个前端框架的 Store。

AI 给过的答案与自己的提案

AI 当时给了我一份很长的审计与修复计划，其中讨论了事件驱动和依赖注入。但计划写得详细，并不代表它真正抓住了问题。我更关心这些方案如何影响业务模块的调用边界，而不是报告里的某个百分比。

我当时的疑问是：

我知道了，我觉得提取这类依赖 store 的 applicationService 的方式是：去除掉将数据保存到 store 的部分，直接返回实体对象值之类的。其余的功能交给 composables。

这个方案更直接：ApplicationService 返回业务实体或结果；组件侧的 Composable 根据页面需要更新 Store。把数据取回来与把它放在哪里显示，不必强制绑在同一层。

这不是一条放之四海而皆准的架构规则

如果多个消费者都要订阅一类持久事件，事件驱动可能确实更合适；如果依赖本来需要运行时注入，依赖注入也有其价值。这里针对的是一次具体的 package 提取阻塞，先切开两种职责，比引入新协调机制更容易解释。

最终我更倾向于先把依赖边界理清，再逐个调整调用关系。事件机制和依赖注入可以作为工具，但不能替代对真实业务流的理解和测试。