领域逻辑下沉到服务层怎么理解？（核心业务规则、分层架构重构手法）路由层

符合最佳实践的部分

进程内共享服务替代 HTTP 自调用。 prepare_interview 和 analyze_job 现在与/v1/agent/interview、/v1/agent/analyze 端点共用同一个服务层函数（services/interview.py、services/analysis.py）。路由只做传输适配，领域逻辑下沉到服务层------这是标准分层架构，消除了自调用的网络往返、鉴权绕行和配置漂移。

文章目录

- "领域逻辑下沉到服务层"是什么意思？
- - [1. 什么是"领域逻辑"（Domain Logic）？](#1. 什么是"领域逻辑"（Domain Logic）？)
  - [2. 什么是"下沉"？](#2. 什么是"下沉"？)
  - [3. 路由只做"传输适配"是什么意思？](#3. 路由只做"传输适配"是什么意思？)
  - 总结一句话

"领域逻辑下沉到服务层"是什么意思？

这句话描述的是一种标准的分层架构重构手法。我们逐词拆解：

1. 什么是"领域逻辑"（Domain Logic）？

就是核心业务规则------与"这个系统到底在做什么"直接相关的代码。

在你给出的场景中：

"准备一场面试"需要哪些步骤？查什么数据、调什么模型、怎么组装结果？
"分析一个岗位"的算法和流程是什么？

这些就是领域逻辑。它们是系统最有价值的部分，跟 HTTP、数据库、消息队列等技术细节无关。

2. 什么是"下沉"？

就是把代码从上层移动到下层。

重构前（逻辑散落在路由层）：

复制代码

路由/控制器层（HTTP 端点）
  ├── /v1/agent/interview    ← 业务逻辑写在这里
  └── /v1/agent/analyze      ← 业务逻辑写在这里

后台任务
  ├── prepare_interview      ← 通过 HTTP 自调用上面的端点 😰
  └── analyze_job            ← 通过 HTTP 自调用上面的端点 😰

问题：业务逻辑被"绑"在了 HTTP 路由上，后台任务想复用就只能发 HTTP 请求给自己（自调用），带来网络开销、鉴权绕行、配置漂移等一系列问题。

重构后（逻辑下沉到服务层）：

复制代码

路由/控制器层（只做传输适配）
  ├── /v1/agent/interview    ← 解析请求 → 调服务层 → 包装响应
  └── /v1/agent/analyze      ← 解析请求 → 调服务层 → 包装响应

服务层（services/）  ← 🎯 领域逻辑在这里
  ├── interview.py           ← 核心业务逻辑
  └── analysis.py            ← 核心业务逻辑

后台任务（直接调用服务层）
  ├── prepare_interview      ← 直接调 services/interview.py ✅
  └── analyze_job            ← 直接调 services/analysis.py ✅

3. 路由只做"传输适配"是什么意思？

路由层变成了一个薄薄的壳，只做三件事：

python 复制代码

# 路由层（薄）
@router.post("/v1/agent/interview")
async def interview_endpoint(request: InterviewRequest):
    # 1. 把 HTTP 请求转成领域对象
    # 2. 调用服务层
    result = await interview_service.prepare(request.to_domain())
    # 3. 把领域结果转成 HTTP 响应
    return InterviewResponse.from_domain(result)

所有"怎么算"的逻辑都在 interview_service.prepare() 里，路由完全不关心。

总结一句话

把"业务怎么算"（领域逻辑）从 HTTP 路由里拿出来，放到一个独立的、不依赖任何传输协议的服务层里。 这样不管是 HTTP 请求还是后台任务，都可以直接调用同一份业务代码，不用再绕一圈发 HTTP 请求给自己。