架构深化审查 — CRM Backend（第二轮）

Problem

ADR-0018 引入「每模块数据档位」后，SysRoleServiceImpl 承担了 两个不同演化轴：角色的基本属性（名称/编码/内置保护）和模块档位的校验规则（哪些 module code 合法、 dataScope 枚举范围）。saveRoleScopes 校验逻辑（50行）比 saveRole 本体更长。getRoleDetail 为了拼装档位展示名需串查 5 个 mapper。新增一个业务模块只需改 ADR-0018 的注册表， 但角色服务的测试也随之需要额外 mock。

Solution

提取 RoleScopeStore 深模块：接口暴露 save / load / delete 三个方法， implementation 内部持有 SysRoleDataScopeMapper + SysDataScopeModuleMapper， 完整吸收档位校验与持久化。SysRoleServiceImpl 只需注入 RoleScopeStore 而非两个 mapper， 测试时一个 mock 替代两个。

Problem

LeadPoolServiceImpl 接口语义是「管理公海池」， 但实现承担了两个完全独立的多值关联表管理：省市区域（lead_pool_province + lead_pool_region）和成员（lead_pool_member）。 这两类数据的修改规则（全量替换语义）完全相同，但业务含义不同。结果是 5 个 mapper 注入， 342 行代码，理解「保存公海池」需要追踪 4 个关注点。

Solution

提取 PoolGeographyStore 和 PoolMemberStore 两个深模块，各自暴露 load / replace 两个方法， 内部管理对应的 mapper 和全量替换逻辑。 LeadPoolServiceImpl 只保留公海池本体 CRUD、事件发布、展示字段填充， 注入依赖从 5 个降到 2 个（IAuthUserService + ISysDeptService，用于展示字段填充）。

Problem

ResourceServiceImpl 的主要职责是管理权限资源树（菜单 catalog/menu/button 的 CRUD）。 但 uploadIcon 把文件存储关注点（扩展名白名单、500KB 限制、FileApi 调用） 引入同一个类。这两个关注点有独立的演化轴：资源树结构变化不影响图标格式规则， 但目前修改其中一个需要理解整个 268 行类。

Solution

提取 IconRepository 端口（1 方法），由 IconRepositoryImpl 适配 FileApi， 内部持有格式/大小校验逻辑。ResourceServiceImpl 依赖端口而非 FileApi——一个 mock 取代两个依赖（FileApi + 校验逻辑）， 且测试不再需要引入 crm-file 模块的 bean。

Problem

RoleController 注入了 ObjectMapper 专门用于 parseModuleScopes——把 JSON 字符串反序列化为 List<ModuleScopeDTO>。 ADR-0017 明确「写操作 POST + @RequestParam，收参对象化」。 Controller 层承担序列化关注点是其余 Controller 没有的例外。

Solution

引入 SaveRoleParam（或给 RoleParam 补字段）绑定 moduleScopes，使用 Spring MVC 的 @RequestBody（如接受切换为 JSON body）或 自定义 @InitBinder 解析。Controller 不再持有 ObjectMapper。