项目的层级架构

区分交互入口、应用编排、领域规则和基础设施适配器，并说明前端状态管理不等于后端的领域层。

#pattern #concept #growing

分层用于分开变化原因和依赖方向，不是要求每个项目都建立固定数量的 service 目录。原图把 Business Service、Domain Service、Application Service 与 Pinia/Vuex 排成一条调用链，混合了业务职责、前端状态和基础设施。

按职责理解

交互入口（HTTP Controller、页面事件、CLI）
→ 应用用例（加载、协调、事务与结果）
→ 领域模型（实体、值对象、必要的领域服务）

应用/领域需要的端口 ← 基础设施适配器实现
                      数据库、HTTP、IPC 等

这是依赖组织示意，不是所有运行时调用都只能向下，也不要求每层一个类。领域服务与应用服务的判断见领域服务与应用服务。

前端状态管理保存视图、会话或编辑草稿；它不因为放在 Pinia 中就成为领域层。API/IPC 客户端负责传输与协议适配，敏感身份与业务授权仍由可信后端或主进程检查。

原例通过 window.shared.ipcRenderer.invoke(“store:read”, username, storeName) 读取存储。这个封装只发出 IPC 请求，泛型返回值并不会验证主进程响应，也不能证明调用者有权访问 username 指定的存储。

主进程需根据可信上下文解析身份、校验允许的存储名并验证消息；preload 暴露具体能力，而不是把任意 IPC 通道开放给渲染层。展示层收到结果后仍需按约定处理错误和数据状态。