项目结构
项目基于 COLA 架构 落地领域驱动设计（DDD），遵循 COLA 标准四层分层规范，结合微服务完成业务模块化拆分。
详细介绍可见：COLA架构实战指南
app 接口接入层
接口接入层，负责接收外部请求（HTTP/ RPC），组装参数，调用领域层，并返回结果。
staff-app / talent-app：具体的应用模块（如员工管理 App、人才管理 App）。
staff / talent：具体业务线的包名。
controller：Controller 控制器，提供 HTTP 接口（REST API）。
converter：DTO 与 DO/Entity 的转换工具（对象映射）。
dto：该应用下的接口数据模型。
service：应用服务实现（协调领域层，处理接口请求逻辑）。
client：应用级别的客户端调用。
infrastructure：应用配置。
mobile / onboarding：特定业务线（如移动端、入职流程）
common 通用层
talent-mgmt-common：通用公共模块，存放全项目通用的工具类、常量、异常、拦截器等。
具体包括：
constants：存放项目全局常量（如状态码、Redis Key 前缀）。
context：上下文信息，通常存储当前登录用户信息、TraceId 等线程级变量。
enums：全局通用枚举类。
exception：全局异常定义（如BusinessException业务异常）。
executor：线程池执行器配置，统一管理异步任务线程。
interceptor：全局拦截器（如日志、鉴权拦截器）。
model：基础数据模型（如 BaseResponse、BaseEntity）。
mybatis：MyBatis 相关配置（如分页插件、类型处理器）。
utils：通用工具类（日期、字符串、JSON、加密等）。
validation：参数校验规则扩展。
domain 领域层，核心业务
ai / offer / talent / user / project：限界上下文（Bounded Context），按业务领域拆分模块，例如人才域、用户域、Offer 域等。
application：应用服务层（协调领域对象完成业务流程）。
manager：领域管理器（管理复杂的领域对象生命周期）。
service：领域服务（处理跨实体的复杂业务逻辑）。
validator：业务规则校验器。
domain：领域核心层。包含领域实体（Entity）、值对象（Value Object）、领域事件、聚合根（Aggregate Root）。这是纯粹的业务逻辑，不依赖外部。
client：领域对外提供的接口（防腐层 / ACL，确保外部调用符合领域规则）。
infrastructure 基础设施层
infrastructure.config：领域基础设施配置（如领域对象的 Repository 实现配置）。
application：基础设施层面的应用服务（如定时任务、外部系统集成）。
client：对外部系统（如第三方 API、其他微服务）的客户端实现（Feign Client）。
domain：领域层接口的具体实现（Repository 的 ORM 实现，对接数据库）。
dto：数据传输对象，用于对外接口通信（req入参，res出参）。
feignClient：微服务间调用的 Feign 客户端声明。
infrastructure：底层技术组件。
cloud：云服务相关配置。
config：配置类（数据源、Redis、MQ 等）。
dify：AI 集成模块（对接 Dify 等 AI 平台）。
mapper：MyBatis Mapper 接口（数据库映射层）。
model：数据库实体（DO/Data Object），与表结构对应。
service：基础设施服务（如 Redis 服务、MQ 消息发送服务）。
四六级证书AI审核
需求分析
针对员工上传【CET4&CET6报告单】的材料，进行真实性核验。
设计
后端项目接收文件，数据读写与展示---Dify工作流解析图片文件------影刀RPA模拟操作到教育考试网验证.
整体流程图如下：
- stf系统，新增工作流客户端、结果类，发布事件，处理工作流逻辑；
- Dify工作流识别提取图片文字（准考证号、身份证号、成绩等信息），组成json消息转发至影刀RPA，识别结果返回给stf；
- stf根据Dify返回作首次判断，ocr识别失败返回异常信息，识别成功则将状态转为RUNNING；
- RPA影刀根据工作流的消息到考试教育网查询验证，查询不到证书信息返回资料不准确，能查询到则比对分数是否一致，比对一致返回验证成功，不一致返回验证失败。（消息返回给stf指定的url）
实现
影刀RPA
RPA（Robotic Process Automation，机器人流程自动化），通过软件机器人模拟人类操作，自动执行规则明确、重复性高的计算机任务，例如数据录入、报表生成、跨系统校验等。
这种技术的优点是：
- 非侵入式，无需修改底层系统，完全模拟人的操作；
- 低错误率，严格按规则执行，避免人在重复劳动中可能的失误；
- 提升效率，处理速度较人工更快，且24小时不间断。
但其本质只是模拟人的输入操作，仍然有很大局限性： - 场景限制，仅适合规则明确、结构化数据的任务；
- 系统脆弱，界面微小变动会导致系统终端，可能需要频繁维护。
RPA执行流程如下：
- 解析输入来自Dify的json，代码实现，从json中提取出姓名（修改为后端发送，避免冒用他人证书）、身份证号、证书编号、考试等级，考试分数（目前采用最新考试规则，总分、听力、阅读、写作和翻译），回调函数，taskid，组合成字典，分别使用变量保存；
- 打开验证网址www.neea.edu.cn
- 进行考试等级判断，根据CET4/CET6选择对应的考试，非法输入提前结束流程，返回状态码INVALID_CERTIFICATE，信息回调到后端
- 根据用户基本信息填写输入框，查询成绩信息；
- 查询结果判断，如果网页出现
您所提供的验证信息可能有误，说明验证失败，状态码为INVALID_CERTIFICATE - 使用xpath获取总分数值，保存变量
- 若获取的总分与输入总分一致，状态码为PASS，抓取列表信息保存为resultData；
- 不一致则返回状态码VALIDATION_FAIL，将输入总分和查询总分组合赋给resultData；
- 判断存在，创建文件夹C：/tmp，验证结果界面截图保存至该文件夹；
- 回调函数将状态码、验证信息和截图文件发给后端
- 关闭网页结束流程
整体工作流程图如下：
暂时先从全国大学英语四、六级考试（含口试）成绩报告单(证书)验证 - 中国教育考试网开始，避免验证问题 。
另外要注意的是：四六级经过三次改革，时间分为87-04.12，05.6-13.6（710分制），13.12至今三部分，各部分分数构成与位置都不同，对比逻辑稍微复杂，暂时只对比总分。
但总分位置也不同，影刀一套逻辑下来会漏项。
- 最粗暴的方法就是写三个逻辑，接收考试信息，匹配不同提取策略，分别处理，这方法有点笨，先尝试其他方法。
- 如果只提取验证总分就变得简单一点，可以用xpath方式获取指定组件及其中数值，这个方法需要会员。（根据指定组件字段筛选，本例中为找出包含
总分的组件，提取其中的值）
工作流编排
- 接受后端消息，file文件，证书格式，taskID等；
- 从证书文件中获取信息，使用千问模型OCR识别基本信息和成绩（格式组织为json）
- 执行判断，成功封装进行后续调用逻辑，否则返回调用失败；
- 成功获取信息则调用方法进行封装，消息传给影刀RPA；
- 返回影刀调用的结果
核心流程如下：
stf系统
整体逻辑：
- 发布事件event；
- service监听自动调用，通用逻辑AuditManager增强具体方法；
- service逻辑调用DifyClientImp具体方法；
- DifyClientImp的连接实例workflow来自DifyManager
主要涉及改动代码如下：
合并代码1075行
亮点
可扩展事件驱动
项目使用可扩展的事件驱动，使用通用发布、审核逻辑，新增事件无需扩展原有方法，大致流程如下：
- AttrAiAuditEvent、AiTaskService 发布审核主事件；
- AiAuditCoordinator 协调器接受主事件，查询附件信息；
- Scanner 初始化扫描审核注解，确定附件信息与事件类
Event映射； - AiAuditCoordinator 协调器读取附件信息，建 Task，根据文件信息二次发布事件；
- Scanner 反射决定实例化具体的类，多附件会发布多个事件
- Spring 按类型发布到指定的监听类
Listener； - CommonAuditManager 进行通用处理，审核附件信息是否完整，复合要求；
- 专用方法传入参数，最后进行特定处理；
- RPA回调按 Task 的 fieldCode 匹配策略，依赖注解中配置的信息。
整体流程图如下：
该设计的目的主要为了贴合业务，相比单个入口对应监听器的方案，该方案有以下好处：
- 统一编排：一次主事件，入口统一，后续扩展只需加 Event 类 + Service，发布者无需调整；
- 可插拔扩展：Event / Service / Strategy 三处扩展，核心流水线不变；
- 横切能力复用 ：通用处理策略
CommonAuditManager；注解AttAiAudit一处声明全程复用； RPA 回调使用注解的FileCode，减缓代码腐败时间； - 业务标识一致 ：全程用
fieldCode，Event 只是进程内分发类型。
单附件修改不会触发全体材料重复审核，该 fieldCode 下最新 att_log 的 aiAuditStatus 非空则跳过，上传路径带有时间戳，只有新上传的文件该记录会为空。
异步可靠性
现有方案另开服务以保持会话状态，部署到生产机上可能断联，导致服务不可用，缺失正确回调，所有服务阻塞到pending等待回调状态，设计以下几种方案解决：
方案一：
轮询任务+自动失败。
轮询修改时间，如果大于超时时间仍然等待回调，自动触发失败逻辑。
优缺点：简单修改小，但不解决根本问题，需重启rpa服务
方案二：
rpa增加心跳接口
后端定时访问rpa，多次未响应标记失败
优缺点：同方案一，rpa多了引起心跳风暴
方案三：
mq解耦+死信
消息由Dify转发至mq，rpa长时间不消费进入死信交换机，通过邮件、短信、钉钉等方式提醒
缺点：实现复杂，引入更多中间件
长期来看方案三稳定性与扩展性最优，但目前仅本项目需要维持会话登录状态，全链路引入 MQ 会徒增整体复杂度。遵循若无必要，勿增实体，最终选用方案一：基于定时轮询做超时失败兜底，同时搭配 RPA 执行失败场景的重试机制，并通过钉钉推送异常告警。