企业官网建设流程全解析

• 文档
• 教程
• 后端

本篇技术指南聚焦《ChatGPT 微服务应用体系构建》系列中 chatgpt-api 工程的第 4 节内容：在完成简单的 SpringBoot API 工程后，如何以领域驱动设计（DDD）架构模型重构工程结构，并实现一个可供 ChatGPT-WEB 页面直接对接使用的流式异步响应接口，让对话内容以"打字机"效果逐字呈现。读者学完本节，将掌握 DDD 分层架构中各个模块的职责边界与依赖关系、抽象出"触发-函数-连接"的开发模型，以及流式应答接口在会话工厂与前端 ReadableStream 中的完整链路设计思路。

一、本章诉求：不只是接口 CRUD，而是工程重构与流式应答

本章最核心的诉求是开发一个可供后续 ChatGPT-WEB 页面使用的异步响应接口，也就是通常使用 ChatGPT 时所体验到的那种逐字输出的打字机效果。Web 页面发送一段对话内容后，后端并不是一次性把完整回答返回，而是通过流式响应的方式持续推送生成中的内容，前端一边接收一边渲染，形成"正在思考、正在打字"的交互体验。

但本节的意义远不止于写一个接口。为了让读者理解如何在真实工程中落地一个功能需求，作者同时完成了两件事：

1. 工程重构：使用 DDD 架构模型重构 chatgpt-api 工程结构，把原本"一个接口搞定所有逻辑"的写法，拆分为职责清晰的多个模块；
2. 设计模式对照：实现"不使用设计模式"和"使用设计模式"两套实现进行对比，帮助读者直观感受设计模式在功能需求代码设计中的作用。

从工程演进脉络看，本节是 chatgpt-api 工程从简单到体系化的转折点。在第 1 节：API工程搭建和简单访问认证中，工程以 SpringBoot 简单工程起步，提供与 Nginx auth_request 模块配合的访问校验接口；到本节则完成 DDD 化重构，为后续第 5 节公众号验证码鉴权登录、第 7 节用户额度账户、第 8 节商品下单对接微信支付等服务模块的落地打下工程骨架。

二、流程设计：DDD 工程结构模型下的 HTTP 响应式调用

整个流程为：以 DDD 工程结构模型承载代码，对外提供 HTTP 响应式接口，接口调用 OpenAI 应答请求信息，将生成结果以流式方式回传给前端。

从流程上看，一次完整的流式对话请求并不复杂，真正的复杂点在于两个方面：

• 如何提供异步响应接口：与传统的同步请求-响应不同，流式接口需要支持持续的数据推送，涉及连接保持、分段返回、前端渐进渲染等一系列设计；
• 如何把调用代码分配到各个类中：一次调用 OpenAI 的请求，涉及参数组装、会话创建、事件监听、应答回调、结果推送等多个环节，这些环节如果没有合理的分层和归类，很快就会变成一坨难以维护的代码。DDD 分层正是为了解决"代码该放哪"的问题。

从系统整体看，chatgpt-api 属于《ChatGPT 微服务应用体系构建》整体架构中的一个微服务节点。整套体系以用户请求为入口，经 Nginx SSL 443 校验转发后，由 chatgpt-api-sdk、chatgpt-auth、chatgpt-wx、chatgpt-pay、chatgpt-zsxq、chatgpt-admin、chatgpt-web 等服务协同完成鉴权、应答、支付等能力。本节重构后的 chatgpt-api 工程，正是这套体系中的后端访问入口与核心服务聚合层。

三、架构讲解：DDD 化的工程重构

1. 模型抽象：从"定义属性 -> 创建方法 -> 调用展示"到"触发 -> 函数 -> 连接"

作者先提出一个简单直观的开发模型："定义属性 -> 创建方法 -> 调用展示"。这个模型对于简单的 CRUD 场景够用，但当工程引入各类分布式技术栈和更多业务逻辑时，它就过于简单了，无法回答"业务逻辑应该沉淀在哪一层、被谁触发、又连接了哪些资源"这类关键问题。

因此在 DDD 场景下，开发代码可以进一步抽象为："触发 -> 函数 -> 连接"，三个环节各有明确的含义：

• 触发：DDD 架构常用于微服务场景，因此一个系统的调用方式不只是 HTTP，还包括RPC 远程调用、MQ 消息、TASK 任务等。这些不同的入口方式都可以理解为"触发"——它们负责把外部请求/事件引入系统，并驱动后续的业务函数执行；
• 函数：可以把各个服务都当成一个函数方法来看。服务内部按照领域职责拆分，每个函数只专注完成一段业务逻辑；
• 连接：函数方法通过"连接"调用到其他的接口、数据库、缓存来完成函数逻辑，也就是领域服务对基础设施资源的访问。

这个模型的意义在于：触发层与业务函数分离、业务函数与资源连接分离，每一部分都有明确的归属和边界，后续无论新增 HTTP 接口、MQ 消费者还是定时任务，都只是在"触发"环节增加入口，而业务函数与资源连接保持不变。

2. 架构分层：七大模块的职责划分

本节给出的 DDD 分层结构是对多种 DDD 实践方式做了简化和处理后的结果，核心重点在于是否适合当前场景的业务开发。以下分层结构与各模块的依赖关系是本节的核心内容：

• 接口定义 - xfg-frame-api：微服务中引用的 RPC 需要对外提供接口的描述信息，调用方在使用时需要引入对应的 Jar 包，以便依赖接口定义做代理调用。这一层承载的是对外暴露的服务契约；
• 应用封装 - xfg-frame-app：应用启动和配置的一层，如 aop 切面、config 配置以及镜像打包都在这一层处理，可以理解为专门为启动服务而存在的一层；
• 领域封装 - xfg-frame-domain：领域模型服务，是最重要的一个模块。无论采用哪种 DDD 分层架构，domain 都是肯定存在的。这一层内会有一个个细分的领域服务，每个服务包中包含【模型、仓库、服务】三部分；
• 仓储服务 - xfg-frame-infrastructure：基础层依赖于 domain 领域层，因为在 domain 层定义了仓储接口，需要在基础层实现。这是依赖倒置的一种设计方式——上层定义契约，下层提供实现；
• 领域封装 - xfg-frame-trigger：触发器层，一般也叫 adapter 适配器层，用于提供接口实现、消息接收、任务执行等操作，是把外部触发接入系统的门面；
• 类型定义 - xfg-frame-types：通用类型定义层，系统开发中会有很多类型定义，包括基本的 Response、Constants 和枚举，会被其他各层引用使用；
• 领域编排【可选】 - xfg-frame-case：领域编排层，一般对于较大且复杂的项目，为了更好的防腐和提供通用的服务，会添加 case/application 层，用于对 domain 领域的逻辑进行封装组合处理。

这套分层与 DDD 通用四层架构（application 应用层、domain 领域层、infrastructure 基础层、interfaces 接口层）一脉相承。仓库中的DDD 专题案例对此有更基础的解释：应用层提供应用服务，领域层承载核心业务模型与仓储接口定义，基础层通过依赖反转方式为各层提供基础资源服务——领域服务和应用服务调用仓储服务接口，由仓储实现完成持久化。xfg-frame-* 模块体系正是这一思想的工程化变体：xfg-frame-api承担 interfaces 的对外契约职责，xfg-frame-trigger承担接口实现与消息接收的适配职责，xfg-frame-domain承载领域模型与仓储接口，xfg-frame-infrastructure实现仓储，xfg-frame-types提供公共类型底座。

四、仓库佐证：流式应答在 SDK 与 WEB 侧的落地链路

流式异步响应接口不是一个孤立的接口开发任务，它在 chatgpt 微服务体系中有着完整的前后端链路。仓库中的 SDK 与 WEB 章节可以印证本节接口设计的上下游关系。

1. SDK 会话模型：统一接口 + 统一会话的事件式流式应答

在 chatgpt-sdk 的第 2 节：流式应答会话设计实现中，SDK 以IOpenAiApi统一接口、OpenAiSession统一会话这两个标准为骨架，封装流式应答操作。流式应答以事件方式接收应答消息，使用方在统一的会话工厂中获得会话接口服务以后，根据接口入参的不同做不同的请求处理。

从 SDK 的设计可以看出，流式应答的核心不是简单的 HTTP 调用，而是"会话模型 + 事件监听"的抽象：会话工厂负责创建会话，会话接口统一暴露对话能力，应答结果通过事件回调逐步上抛。这种以 MyBatis 会话模型为参照的设计，恰好对应了本节 DDD 分层中"触发 -> 函数 -> 连接"的思想——会话接口是函数入口，事件监听是应答的连接通道。对于 chatgpt-api 第 4 节要开发的流式异步响应接口而言，SDK 的这一层会话能力正是其底层依赖：API 层负责接收 HTTP 请求触发会话，SDK 负责建立连接并持续回调应答数据。

2. 前端打字机效果：fetch 与 ReadableStream 的对接

在 chatgpt-web 的第 8 节：流式接口对接中明确说明：在 ChatGPT-API 工程模块下，流式异步响应接口已经开发并测试完成，WEB 侧在此基础上做对接，让前端以打字机效果展示对话内容。这一节印证了本节接口的设计目标与验收标准。

前端对接的核心技术点包括：

• 跨域处理，将发送时的请求信息传递给后端；
• 使用 fetch 调用接口发起流式请求；
• 使用ReadableStream处理流式返回数据，将后端分段推送的内容依次填充到消息记录与展示对话框中，实现内容的渐显效果。

由此可以还原完整的链路：用户在前端输入对话 -> fetch 发起请求 -> chatgpt-api 的流式异步响应接口接收触发 -> 调用 chatgpt-sdk 会话接口 -> OpenAI 逐段返回 -> 事件回调 -> 接口将内容以流式数据写回 -> 前端 ReadableStream 逐段读取渲染。本节开发的接口正是这条链路中连接前端与 SDK 的枢纽。

3. 设计模式对照的意义与后续落地

本节提出的"使用设计模式与不使用设计模式"对照开发，其价值在于让读者在相同的功能需求下，看到两种写法的差异：不使用设计模式时，接口逻辑会随着触发方式增多（HTTP、MQ、RPC、任务）而不断膨胀，if-else 分支蔓延；使用设计模式（如策略、工厂、责任链）后，不同渠道、不同触发方式被抽象为可替换的策略实现，新增渠道只需扩展实现类而无需改动核心调用逻辑。

这一思想在后继章节中有直接印证：chatgpt-api 的第 9 节：OpenAi多渠道策略模式正是以策略模式落地多渠道对接；而第 5 节：公众号发送验证码鉴权登录则明确基于 DDD 架构，将鉴权、微信公众号、OpenAI 三个服务模块拆分实现——这正是本节 DDD 重构成果的直接复用。可以说，本节既交付了一个可运行的流式异步响应接口，也交付了一套可持续承载后续业务模块的 DDD 工程骨架。

五、总结

本节的核心交付物有两个：

1. 流式异步响应接口：以 HTTP 响应式方式调用 OpenAI 并逐段回传应答，满足 WEB 前端打字机效果的对接要求，接口之上是"会话工厂 + 事件监听"的 SDK 支撑，之下是 fetch 与 ReadableStream 的前端渲染；
2. DDD 工程重构骨架：以xfg-frame-api（接口定义）、xfg-frame-app（应用封装）、xfg-frame-domain（领域封装）、xfg-frame-infrastructure（仓储服务）、xfg-frame-trigger（触发器层）、xfg-frame-types（类型定义）、xfg-frame-case（领域编排）七模块分层，配合"触发 -> 函数 -> 连接"的开发模型，让工程具备应对多触发方式、多业务领域、多资源连接的扩展能力。

对读者而言，本节最有价值的学习点在于：一个看似简单的流式接口需求，如何通过 DDD 分层与设计模式对照，被拆解为职责清晰的模块化实现——这是从"会写接口"走向"会设计工程"的关键一步。

• 文档
• 教程
• 后端