文档教程后端【免费下载链接】CodeGuide:books: 本代码库是作者小傅哥多年从事一线互联网 Java 开发的学习历程技术汇总旨在为大家提供一个清晰详细的学习教程侧重点更倾向编写Java核心内容。如果本仓库能为您提供帮助请给予支持(关注、点赞、分享)项目地址https://gitcode.com/gh_mirrors/code/CodeGuide点击查看免费下载本篇技术指南聚焦《ChatGPT 微服务应用体系构建》系列中 chatgpt-api 工程的第 4 节内容在完成简单的 SpringBoot API 工程后如何以领域驱动设计DDD架构模型重构工程结构并实现一个可供 ChatGPT-WEB 页面直接对接使用的流式异步响应接口让对话内容以打字机效果逐字呈现。读者学完本节将掌握 DDD 分层架构中各个模块的职责边界与依赖关系、抽象出触发-函数-连接的开发模型以及流式应答接口在会话工厂与前端 ReadableStream 中的完整链路设计思路。一、本章诉求不只是接口 CRUD而是工程重构与流式应答本章最核心的诉求是开发一个可供后续 ChatGPT-WEB 页面使用的异步响应接口也就是通常使用 ChatGPT 时所体验到的那种逐字输出的打字机效果。Web 页面发送一段对话内容后后端并不是一次性把完整回答返回而是通过流式响应的方式持续推送生成中的内容前端一边接收一边渲染形成正在思考、正在打字的交互体验。但本节的意义远不止于写一个接口。为了让读者理解如何在真实工程中落地一个功能需求作者同时完成了两件事工程重构使用 DDD 架构模型重构 chatgpt-api 工程结构把原本一个接口搞定所有逻辑的写法拆分为职责清晰的多个模块设计模式对照实现不使用设计模式和使用设计模式两套实现进行对比帮助读者直观感受设计模式在功能需求代码设计中的作用。从工程演进脉络看本节是 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 工程骨架。五、总结本节的核心交付物有两个流式异步响应接口以 HTTP 响应式方式调用 OpenAI 并逐段回传应答满足 WEB 前端打字机效果的对接要求接口之上是会话工厂 事件监听的 SDK 支撑之下是 fetch 与 ReadableStream 的前端渲染DDD 工程重构骨架以xfg-frame-api接口定义、xfg-frame-app应用封装、xfg-frame-domain领域封装、xfg-frame-infrastructure仓储服务、xfg-frame-trigger触发器层、xfg-frame-types类型定义、xfg-frame-case领域编排七模块分层配合触发 - 函数 - 连接的开发模型让工程具备应对多触发方式、多业务领域、多资源连接的扩展能力。对读者而言本节最有价值的学习点在于一个看似简单的流式接口需求如何通过 DDD 分层与设计模式对照被拆解为职责清晰的模块化实现——这是从会写接口走向会设计工程的关键一步。赞分享文档教程后端【免费下载链接】CodeGuide:books: 本代码库是作者小傅哥多年从事一线互联网 Java 开发的学习历程技术汇总旨在为大家提供一个清晰详细的学习教程侧重点更倾向编写Java核心内容。如果本仓库能为您提供帮助请给予支持(关注、点赞、分享)项目地址https://gitcode.com/gh_mirrors/code/CodeGuide点击查看免费下载相关推荐DBeaver 数据比较结果过滤3 步只看你关心的差异DBeaver 数据比较结果过滤3 步只看你关心的差异 DBeaver 的数据比较功能会把差异完整列出来数量常常多于你真正要处理的部分。本文带你用大约 3数据库客户端桌面应用数据库终极指南ChatGPT微盘股实验安全响应体系构建与风险管控策略终极指南ChatGPT微盘股实验安全响应体系构建与风险管控策略 GitHub推荐项目精选中的LLM Trading Lab项目展示了ChatGPT管理真实资金人工智能金融科技数据分析科研Cycle.js微前端构建流程实现响应式应用的独立构建Cycle.js微前端构建流程实现响应式应用的独立构建 你还在为大型前端应用的构建效率低下而困扰吗当团队规模扩大传统单体应用往往面临代码冲突频繁、构建时间前端Web框架上一篇使用rumps开发macOS状态栏应用从入门到实践下一篇Npcap开发教程从网络适配器列表到数据包捕获创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
`/`ref()` 引用与 `forceEntityConstructor`)
