架构设计

后端按四层处理请求，职责单向依赖、不可反向调用：

请求 → Controller → Service → Repository → Model
                      ↓（提交后）
                 afterCommit / 队列进程

分层职责

层	做什么
Controller	收参、校验、调 Service、组响应。不写业务、不直接查库。
Service	业务编排与事务。只调 Repository；写操作包在 runInTransaction() 里，必须在数据落库后再做的副作用用 afterCommit()。
Repository	唯一与 Model 交互的层。查询一律从 $this->query() 起手（受控表在这里挂上数据权限）。
Model	表映射与关联。不写业务流程。

请求怎么走

以新建角色为例（RoleController::store → RoleService::createRole → RoleRepository）：

1. 路由组挂上认证与权限中间件后进入控制器。
2. 控制器用私有规则校验请求体，把 $this->validate() 的返回值交给 Service。
3. Service 在 runInTransaction() 里调 Repository 落库；需要清缓存时注册 afterCommit()。
4. Repository 经 query() / create() 访问 Model。

异步副作用

不必阻塞响应的副作用（例如管理端写操作日志）由中间件在请求内算好载荷，再投递到 Redis 队列；独立的队列进程消费并落库。config/queue.php 登记队列名与消费者（如 operation-log → OperationLogConsumer），由 webman/redis-queue 的队列进程执行。

常驻内存下，Service 与中间件是容器单例：不要在实例属性里存请求态，请求态放 support\Context 或当次 $request。