furniture-3d-system-Wu/furniture-3d-system/docs/solutions/workflow-issues/service-repository-layering-user-service-20260215.md

title, date, module, problem_type, severity, symptoms, root_cause, resolution_type, status, confidence, tags, related_patterns

title	date	module	problem_type	severity	symptoms	root_cause	resolution_type	status	confidence	tags	related_patterns
User Service 直连 Prisma 导致分层失效	2026-02-15	user-service	workflow_issue	high	user.service.ts 中直接调用 prisma.user/prisma.department/prisma.team Service 层同时承担数据访问与业务编排，破坏企业分层边界	历史实现未统一收口到 Repository 层	code_fix	active	high	architecture service-layer repository-layer user-service

现象与影响

用户服务在列表、详情、创建、更新、删除、登录校验等场景直接访问 Prisma，导致：

• Service 层和 Repository 层职责重叠，后续治理难度上升。
• 权限/规则与数据查询耦合，复用困难。
• 审查时难以快速确认“Route -> Service -> Repository”是否被遵守。

排查路径

1. 在 src/server/services/user.service.ts 全量搜索 prisma.。
2. 将命中的查询按“读/写/校验”分类，映射到应由 Repository 承担的方法。
3. 检查 src/server/repositories/user.repository.ts 现有能力是否可复用，不足则补充原子方法。

根因分析

用户模块早期实现以功能闭环优先，缺少统一分层约束落地，随着功能堆叠形成了 Service 直连数据库的路径依赖。

最终修复

代码改动

• 重写 src/server/services/user.service.ts，移除全部 Prisma 直连，Service 仅保留：
  • 输入校验
  • 业务规则判定
  • 调用 Repository 编排
• 扩展 src/server/repositories/user.repository.ts：
  • findByEmailWithRelations
  • findByNameWithRelations
  • createWithScalars
  • updateWithScalars
  • departmentIds 过滤支持

验证命令

• npm run type-check -- --pretty false（通过）
• npm test -- tests/api/auth-me.test.ts --runInBand（通过）

预防策略

• 新增 Service 逻辑时，先在 Repository 层补齐原子数据方法，再编写 Service 编排。
• Code Review 增加硬性检查：Service 文件若出现 prisma. 直接判为架构违规。
• 对已存在的 Service 分批治理，优先处理 P0/P1 的权限与数据一致性链路。

剪枝与冲突检查

• 本次未发现可直接剪枝的旧模式（首次沉淀该类模式）。
• 本次未发现同触发条件下的冲突模式。