本文主題解釋模塊為什么能互相使用以及 Maven、Spring 和公共接口分別承擔什么職責適合讀者剛接觸 Maven 多模塊、Spring 依賴注入和模塊化單體架構的 Java 開發(fā)者代碼基線當前學習分支源碼快照上一篇從零讀懂 AI 智能客服后端架構模塊職責與 SSE 聊天鏈路下一篇AI 智能客服為什么不能照搬傳統(tǒng)三層架構CRUD 與 AI 編排分層對比這里是yurenpai27屆開發(fā)者主要學習 Java 后端與 AI 應用開發(fā)。這里記錄真實項目中的代碼調用鏈、Agent/RAG 工程化、問題排查和開發(fā)復盤。個人理念模塊之間能否協(xié)作不能只看目錄位置必須同時追蹤構建依賴和運行時裝配。寫在前面先說結論兩個模塊放在同一個倉庫里并不代表它們可以直接互相調用。真正決定模塊協(xié)作的是三層機制Maven 負責建立編譯依賴Spring 負責發(fā)現(xiàn)并注入運行時 Bean公共接口負責控制依賴方向、避免業(yè)務模塊形成循環(huán)依賴。本文會以“聊天模塊調用工作流、工作流反向使用聊天能力”為貫穿案例重點講清父子關系、聚合關系和依賴關系有什么區(qū)別admin為什么能夠把多個業(yè)務模塊裝進同一個應用接口放在公共模塊中為什么能避免chat ? aiflow的循環(huán)依賴如何用 POM、import、接口實現(xiàn)和啟動模塊反向驗證一次跨模塊調用。說明本文以當前項目源碼為例重點解釋模塊協(xié)作方法不同項目的模塊名稱可能不同但分析步驟可以復用。代碼說明除明確標注為完整源碼外文中的 POM、Java 代碼和目錄片段均為根據當前源碼整理的簡化示意文中的“已核對”表示完成靜態(tài)源碼核對不等同于啟動或接口測試通過。一、為什么要拆成這么多模塊假設不拆模塊把所有代碼都放在一個項目中src/main/java/com/tst/pharma/ ├─ 用戶管理 ├─ 權限管理 ├─ 聊天 ├─ 知識庫 ├─ 工作流 ├─ AI 流程 ├─ Redis ├─ SSE ├─ 短信 ├─ 文件上傳 ├─ Excel └─ 定時任務時間長了會出現(xiàn)幾個問題1. 所有代碼混在一起不知道屬于哪個業(yè)務 2. 一個聊天模塊也能隨便依賴用戶、短信、工作流內部實現(xiàn) 3. 公共工具被復制多份 4. 修改一個模塊容易影響其他模塊 5. Maven 依賴越來越混亂 6. 新人很難判斷代碼應該放在哪里 7. 無法控制模塊之間的依賴方向。所以項目進行了兩次拆分。第一次按大職責拆分tst-pharma-admin ├─ 應用啟動和組裝 tst-pharma-common ├─ 公共基礎能力 tst-pharma-modules ├─ 具體業(yè)務模塊 tst-pharma-extend └─ 獨立擴展服務第二次在每個大模塊內部繼續(xù)拆分例如公共能力拆成tst-pharma-common-core tst-pharma-common-web tst-pharma-common-redis tst-pharma-common-sse tst-pharma-common-mybatis tst-pharma-common-satoken業(yè)務能力拆成tst-pharma-system tst-pharma-chat tst-pharma-workflow tst-pharma-aiflow tst-pharma-generator這樣就可以做到聊天模塊需要 SSE → 只依賴 common-sse 聊天模塊需要 Web 能力 → 只依賴 common-web 聊天模塊不需要短信 → 就不必直接依賴 common-sms這就是“模塊化”的主要意義不是為了把目錄弄多而是為了劃分職責、復用能力并控制依賴。二、先區(qū)分三個容易混淆的概念項目中有三種關系一定要區(qū)分。1. 父子關系例如子模塊的pom.xml中parentgroupIdcom.tst.pharma/groupIdartifactIdtst-pharma-main-backend/artifactIdversion${revision}/version/parent它表示子模塊繼承父工程的版本號 依賴版本管理 Maven 插件 Java 版本 構建配置但是繼承父 POM不代表父模塊能夠直接使用子模塊的 Java 類。2. 聚合關系根pom.xml中modulesmoduletst-pharma-admin/modulemoduletst-pharma-common/modulemoduletst-pharma-extend/modulemoduletst-pharma-modules/module/modules它表示在根目錄執(zhí)行 Maven 構建時 → Maven 會一起構建這些模塊但是被根 POM 聚合也不等于模塊之間能夠互相調用。例如tst-pharma-chat tst-pharma-workflow雖然都被根項目聚合但如果chat/pom.xml沒有依賴workflow那么chat不能直接隨意導入workflow的類。3. 依賴關系真正決定一個模塊能否使用另一個模塊 Java 類的是dependencygroupIdcom.tst.pharma/groupIdartifactId被依賴模塊/artifactId/dependency例如tst-pharma-chat/pom.xml中有dependencygroupIdcom.tst.pharma/groupIdartifactIdtst-pharma-common-chat/artifactId/dependencydependencygroupIdcom.tst.pharma/groupIdartifactIdtst-pharma-common-sse/artifactId/dependency所以聊天模塊才能使用importcom.tst.pharma.common.chat.domain.dto.request.ChatRequest;importcom.tst.pharma.common.sse.core.SseEmitterManager;可以記成聚合關系 └─ 決定一起構建 父子關系 └─ 決定繼承統(tǒng)一配置 依賴關系 └─ 決定是否能使用另一個模塊的代碼小魚點睛父子關系統(tǒng)一配置聚合關系決定一起構建依賴關系決定能否使用對方的 Java 類。兩個目錄即使緊挨在一起也不會自動產生代碼依賴。三、項目真實的模塊依賴方向整個項目可以簡化成tst-pharma-admin 主應用啟動和組裝 │ ┌───────────────────┼────────────────────┐ │ │ │ ▼ ▼ ▼ tst-pharma-system tst-pharma-chat tst-pharma-workflow 系統(tǒng)管理業(yè)務 AI聊天與知識庫 傳統(tǒng)業(yè)務流程 │ ▼ tst-pharma-aiflow AI流程編排 上述業(yè)務模塊繼續(xù)依賴 tst-pharma-common-* 公共基礎組件更準確地說admin直接依賴tst-pharma-system tst-pharma-generator tst-pharma-chat tst-pharma-workflow tst-pharma-aiflow因此最終啟動admin時這些業(yè)務模塊都會進入主應用。四、admin是怎么把所有業(yè)務模塊裝進來的文件D:\Tools\java\aiwork\tst-pharma-main-backend\tst-pharma-admin\pom.xml它聲明了admin ├─ 依賴 system ├─ 依賴 generator ├─ 依賴 chat ├─ 依賴 workflow └─ 依賴 aiflow構建主應用時Maven 會把這些模塊的編譯產物和依賴一起放進最終應用?？梢詫⒆罱K運行的應用理解成tst-pharma-admin.jar ├─ admin 自己的類 ├─ system 模塊的類 ├─ chat 模塊的類 ├─ workflow 模塊的類 ├─ aiflow 模塊的類 ├─ generator 模塊的類 └─ 它們所依賴的 common 類因此運行時主要是一個 JVM 進程 一個 Spring 容器 一個后端端口 6039而不是system 啟一個端口 chat 啟一個端口 workflow 啟一個端口 aiflow 再啟一個端口所以當前主體架構屬于模塊化單體應用不是微服務架構。五、公共模塊是怎么被業(yè)務模塊使用的例子一聊天模塊使用 SSEChatServiceFacade中privatefinalSseEmitterManagersseEmitterManager;SseEmitterManager不在聊天模塊而在tst-pharma-common-sse聊天模塊的pom.xml聲明了dependencygroupIdcom.tst.pharma/groupIdartifactIdtst-pharma-common-sse/artifactId/dependency完整關系是tst-pharma-chat │ │ Maven 依賴 ▼ tst-pharma-common-sse │ ├─ SseEmitterManager ├─ SseMessageUtils ├─ SseEventDto └─ SSE 自動配置于是聊天模塊才能建立 SSE 發(fā)送 content 發(fā)送 done 發(fā)送 error 關閉 SSE例子二聊天模塊使用登錄認證聊天代碼中使用LoginHelper.getUserId(); StpUtil.getTokenValue();這涉及common-satoken common-redis Sa-Token依賴鏈不一定都由聊天模塊直接聲明也可以通過依賴傳遞獲得。簡化理解tst-pharma-chat ↓ common-chat / common-sse / common-web ↓ common-satoken ↓ common-redis ↓ Redis所以一個模塊不一定需要把所有底層依賴都重新聲明一遍。例子三系統(tǒng)模塊使用 MyBatisSysConfigMapperpublicinterfaceSysConfigMapperextendsBaseMapperPlusSysConfig,SysConfigVo{}其中BaseMapperPlus位于tst-pharma-common-mybatis關系為tst-pharma-system │ ▼ tst-pharma-common-mybatis │ ▼ MyBatis-Plus │ ▼ MySQL因此system模塊不需要自己再實現(xiàn)一套分頁、Mapper 基類和數(shù)據庫配置。六、模塊之間不僅靠 Maven還靠 Spring 連接Maven 解決的是編譯時能不能看到另一個模塊的類Spring 解決的是程序啟動后具體使用哪個實現(xiàn)對象啟動類D:\Tools\java\aiwork\tst-pharma-main-backend\tst-pharma-admin\src\main\java\com\tst\pharma\TstPharmaApplication.java位于根包packagecom.tst.pharma;并且有SpringBootApplicationSpring 默認會從啟動類所在包向下掃描com.tst.pharma ├─ controller ├─ service ├─ config ├─ factory ├─ workflow └─ ...即使類分別位于不同 Maven 模塊中只要最后都被admin引入并且包名屬于com.tst.pharma...Spring 就能發(fā)現(xiàn)它們。例如chat 模塊 └─ ChatController └─ Controller chat 模塊 └─ ChatServiceFacade └─ Service aiflow 模塊 └─ WorkflowStarter └─ Spring Bean common-sse 模塊 └─ SSE 自動配置 └─ 注冊 SseEmitterManager它們最后都在同一個 Spring 容器中。七、Spring 依賴注入是怎么跨模塊工作的例如ChatController中privatefinalChatServiceFacadechatService;因為類上有RequiredArgsConstructorLombok 會生成類似構造器publicChatController(ChatServiceFacadechatService){this.chatServicechatService;}Spring 啟動時發(fā)現(xiàn)ChatController 需要 ChatServiceFacade然后又發(fā)現(xiàn)ServicepublicclassChatServiceFacade{}于是完成注入Spring 容器 ├─ 創(chuàng)建 ChatServiceFacade ├─ 創(chuàng)建 ChatController └─ 把 ChatServiceFacade 放進 ChatController雖然它們處在不同目錄甚至不同 Maven 模塊也不影響運行時注入只要滿足1. admin 的 Maven 依賴把兩個模塊裝進來了 2. Spring 掃描到了對應類 3. 類注冊成了 Bean 4. 依賴類型能夠匹配。小魚點睛Maven 只解決“編譯時能不能看見接口和類”真正把接口字段連接到實現(xiàn)對象的是 Spring 容器。只有編譯依賴、Bean 掃描和類型匹配同時成立跨模塊注入才會成功。八、項目中最典型的跨模塊設計common-chat接口橋梁這一部分很重要因為它解釋了chat和aiflow為什么可以互相協(xié)作但沒有在 POM 中直接互相依賴。先看結構tst-pharma-common-chat ├─ IChatService ├─ IChatModelService └─ IWorkFlowStarterService它們只是接口和公共協(xié)議不包含具體業(yè)務實現(xiàn)。聊天服務接口位于tst-pharma-common-chat └─ IChatService具體實現(xiàn)位于聊天模塊ServicepublicclassChatServiceFacadeimplementsIChatService{}關系common-chat └─ 定義 IChatService chat └─ ChatServiceFacade 實現(xiàn) IChatService工作流啟動接口位于tst-pharma-common-chat └─ IWorkFlowStarterService具體實現(xiàn)位于 AI 流程模塊publicclassWorkflowStarterimplementsIWorkFlowStarterService{}關系common-chat └─ 定義 IWorkFlowStarterService aiflow └─ WorkflowStarter 實現(xiàn) IWorkFlowStarterServicechat 調用 aiflowChatServiceFacade中不是直接依賴某個aiflow內部類而是privatefinalIWorkFlowStarterServiceworkFlowStarterService;流程是ChatServiceFacade │ │ 只認識公共接口 ▼ IWorkFlowStarterService ▲ │ 由 Spring 在運行時尋找實現(xiàn) │ WorkflowStarter這樣chat模塊在編譯時不需要直接依賴aiflow。aiflow 調用 chataiflow的WorkflowUtil中使用privateIChatServicechatService;privateIChatModelServicechatModelService;流程WorkflowUtil │ │ 只依賴公共接口 ▼ IChatService ▲ │ Spring 注入實現(xiàn) │ ChatServiceFacade所以整體是common-chat 公共接口和公共請求對象 ▲ ▲ │ │ chat aiflow 實現(xiàn)聊天接口 實現(xiàn)流程接口這叫通過公共契約解耦業(yè)務模塊。小魚點睛把接口下沉到雙方都能依賴的公共模塊目的不只是“集中存放公共類”而是反轉依賴方向業(yè)務模塊面向穩(wěn)定契約協(xié)作避免chat和aiflow在 POM 中相互咬住。九、為什么接口要放在common-chat而不是直接放在chat如果IChatService放在tst-pharma-chat那么aiflow為了調用它就必須aiflow → 依賴 chat同時聊天模塊為了啟動 AI 工作流可能又需要chat → 依賴 aiflow最后形成chat → aiflow ↑ ↓ └───────┘這就是 Maven 循環(huán)依賴。Maven 無法正常處理這樣的模塊關系。當前項目把接口放進公共模塊后變成chat ──────→ common-chat aiflow ────→ common-chat然后由admin同時引入admin ├─ chat └─ aiflow運行時再由 Spring 把實現(xiàn)連接起來。這個設計可以理解為插座common-chat └─ 規(guī)定插座形狀 chat └─ 提供一種插頭 aiflow └─ 提供或使用另一種插頭 Spring └─ 啟動時把兼容的插頭插到插座上十、admin是最終的組裝者這個項目中真正知道“我要同時加載哪些業(yè)務模塊”的是tst-pharma-admin它的pom.xml相當于組裝清單主應用需要 ├─ system ├─ generator ├─ chat ├─ workflow └─ aiflow因此可以這樣理解common └─ 制造公共零件 modules ├─ 制造用戶系統(tǒng) ├─ 制造聊天系統(tǒng) ├─ 制造業(yè)務工作流 └─ 制造 AI 工作流 admin └─ 把所有零件和業(yè)務模塊裝成完整應用十一、數(shù)據庫 Mapper 又是怎么跨模塊加載的配置位于D:\Tools\java\aiwork\tst-pharma-main-backend\tst-pharma-admin\src\main\resources\application.yml其中配置了mybatis-plus:mapperPackage:com.tst.pharma.**.mappermapperLocations:classpath*:mapper/**/*Mapper.xmltypeAliasesPackage:com.tst.pharma.**.domainMyBatis 配置類使用MapperScan(${mybatis-plus.mapperPackage})意思是掃描所有模塊中符合下面規(guī)則的 Mappercom.tst.pharma.任意內容.mapper例如system 模塊 └─ com.tst.pharma.system.mapper.SysConfigMapper chat 模塊 └─ com.tst.pharma.mapper.ChatMessageMapper workflow 模塊 └─ 對應的 mapperclasspath*:也表示不只查當前模塊還會查依賴 JAR 中的 Mapper XML。所以啟動一個admin能夠把多個業(yè)務模塊中的 Mapper 全部注冊到同一個 MyBatis/Spring 容器。十二、配置文件如何影響所有模塊主要運行配置集中在tst-pharma-admin\src\main\resources\application.yml tst-pharma-admin\src\main\resources\application-dev.yml這里配置端口 數(shù)據庫 Redis MyBatis Sa-Token 多租戶 日志 SSE 上傳目錄雖然配置文件在admin但 Spring 啟動后創(chuàng)建的是一個統(tǒng)一環(huán)境。因此system 模塊可以使用數(shù)據源 chat 模塊可以使用數(shù)據源 workflow 模塊可以使用 Redis common-sse 可以讀取 SSE 配置 common-satoken 可以讀取認證配置它們不需要各自維護一套application.yml?？梢岳斫獬蒩dmin application.yml │ ▼ Spring Environment ├─ system 使用 ├─ chat 使用 ├─ workflow 使用 ├─ aiflow 使用 └─ common 組件使用十三、數(shù)據庫和 Redis 也是模塊之間的公共基礎設施當前主要業(yè)務模塊運行在同一個應用中并共享MySQL Redis 登錄狀態(tài) 租戶上下文 事務管理器 SSE 連接管理例如一次聊天請求可能發(fā)生chat 模塊 ├─ 從 chat_model 表查詢模型配置 ├─ 從 chat_message 表查詢歷史消息 ├─ 從 knowledge_info 表查詢知識庫配置 ├─ 使用 Redis/登錄上下文獲取認證信息 └─ 使用 SSE 向當前用戶發(fā)送結果但要注意共享同一個數(shù)據庫不代表模塊應該隨意直接修改其他模塊的表。正常情況下應優(yōu)先模塊 A → 調用公共接口 → 模塊 B 的 Service → 模塊 B 的 Mapper → 模塊 B 負責自己的表而不是模塊 A → 直接拿模塊 B 的 Mapper → 隨意修改模塊 B 的表否則模塊邊界會再次被破壞。十四、用聊天請求看模塊之間如何真正協(xié)作一次POST /chat/send背后會經過很多模塊?？蛻舳苏埱?│ ▼ common-web / common-satoken ├─ Web 請求處理 ├─ 登錄認證 └─ 用戶上下文 │ ▼ tst-pharma-chat ├─ ChatController ├─ ChatServiceFacade ├─ 場景分類 └─ 模型調用 │ ├──────────────┐ ▼ ▼ common-sse common-chat SSE連接和事件 公共請求對象和接口 │ │ │ ├─────────────┐ │ ▼ ▼ │ aiflow chat實現(xiàn) │ AI流程啟動 模型聊天實現(xiàn) │ ▼ 瀏覽器逐段接收回復如果是普通聊天ChatController → ChatServiceFacade → ChatModelService → ChatServiceFactory → 模型供應商實現(xiàn) → LangChain4j → 外部模型接口 → common-sse → 前端如果是 AI 工作流ChatController → ChatServiceFacade → IWorkFlowStarterService → aiflow 中的 WorkflowStarter → AI 工作流節(jié)點執(zhí)行 → 需要模型時調用 IChatService → chat 中的 ChatServiceFacade → 模型這就是多個模塊之間的真實協(xié)作。十五、extend為什么沒有被直接裝進admin根 POM 聚合了tst-pharma-extend所以執(zhí)行根 Maven 構建時會一起構建monitor-admin snailjob-server但是admin/pom.xml沒有把它們作為主業(yè)務依賴引入。這說明根 POM 聚合它們 ≠ admin 運行時包含它們它們更可能是獨立啟動的擴展服務主后端 └─ tst-pharma-admin 監(jiān)控服務 └─ tst-pharma-monitor-admin 任務調度服務 └─ tst-pharma-snailjob-server所以再次強調聚合 └─ 一起構建 依賴 └─ 編譯和運行時使用十六、當前項目的核心模塊關系圖可以先保存這張圖tst-pharma-main-backend │ ├─ tst-pharma-common │ ├─ common-core │ │ └─ 最底層公共對象、異常、工具 │ │ │ ├─ common-redis │ │ └─ 依賴 common-core │ │ │ ├─ common-satoken │ │ └─ 依賴 common-core、common-redis │ │ │ ├─ common-mybatis │ │ └─ 依賴 common-core、common-satoken │ │ │ ├─ common-sse │ │ └─ 依賴 core、redis、satoken、json │ │ │ ├─ common-web │ │ └─ Web 公共能力 │ │ │ └─ common-chat │ ├─ 依賴 core │ ├─ 依賴 sse │ ├─ 依賴 mybatis │ └─ 定義聊天、模型、工作流公共接口 │ ├─ tst-pharma-modules │ ├─ system │ │ └─ 依賴 MyBatis、Web、認證、租戶等公共模塊 │ │ │ ├─ chat │ │ ├─ 依賴 common-chat │ │ ├─ 依賴 common-sse │ │ ├─ 依賴 common-web │ │ └─ 實現(xiàn) IChatService、IChatModelService │ │ │ ├─ aiflow │ │ ├─ 依賴 common-chat │ │ ├─ 使用 IChatService │ │ └─ 實現(xiàn) IWorkFlowStarterService │ │ │ ├─ workflow │ │ └─ 依賴 MyBatis、Web、租戶、認證等公共模塊 │ │ │ └─ generator │ └─ 依賴 MyBatis、Web、文檔、日志等公共模塊 │ ├─ tst-pharma-admin │ ├─ 引入 system │ ├─ 引入 chat │ ├─ 引入 workflow │ ├─ 引入 aiflow │ ├─ 引入 generator │ └─ 啟動一個完整 Spring Boot 應用 │ └─ tst-pharma-extend ├─ monitor-admin └─ snailjob-server十七、判斷“兩個模塊怎么關聯(lián)”的固定方法以后看到兩個模塊不要憑目錄名猜可以按下面五步確認。第一步看調用模塊的pom.xml例如想知道chat能不能使用common-sse打開 tst-pharma-chat/pom.xml 搜索 tst-pharma-common-sse如果有依賴說明編譯時可見。第二步看 Javaimport例如importcom.tst.pharma.common.sse.core.SseEmitterManager;說明代碼確實使用了該模塊的類。第三步看字段注入類型例如privatefinalIWorkFlowStarterServiceworkFlowStarterService;說明當前類依賴的是接口。第四步查誰實現(xiàn)接口搜索implements IWorkFlowStarterService找到aiflow → WorkflowStarter第五步確認最終啟動模塊是否同時引入雙方查看tst-pharma-admin/pom.xml確認同時依賴chat aiflow這樣 Spring 運行時才有機會把它們連接起來。十八、核心結論結論一目錄相鄰 ≠ 有依賴關系真正的編譯依賴看pom.xml 中的 dependency結論二根 POM 中有 module ≠ 該模塊被裝進主應用它可能只是一起構建。結論三admin 是主應用組裝者它把system、chat、workflow、aiflow、generator放進同一個 Spring Boot 應用。結論四common 提供公共能力和公共接口 modules 提供具體業(yè)務實現(xiàn)結論五模塊之間推薦通過公共接口 Spring 依賴注入進行協(xié)作而不是互相直接依賴內部實現(xiàn)。結論六當前主體不是微服務而是模塊化單體 ├─ 編譯時分模塊 ├─ 代碼職責分模塊 └─ 運行時主要在同一個 Spring Boot 進程最典型的真實關系就是ChatServiceFacade │ │ 實現(xiàn) ▼ IChatServicecommon-chat ▲ │ 使用 │ WorkflowUtilaiflow以及反方向WorkflowStarteraiflow │ │ 實現(xiàn) ▼ IWorkFlowStarterServicecommon-chat ▲ │ 使用 │ ChatServiceFacadechat它們由admin同時組裝再由 Spring 在運行時連接。這個例子基本涵蓋了整個項目模塊化設計的核心?？偨Y本文圍繞“解釋模塊為什么能互相使用以及 Maven、Spring 和公共接口分別承擔什么職責”主要分析了父子、聚合和依賴三種 Maven 關系的邊界啟動模塊如何完成業(yè)務模塊的最終組裝Spring 如何跨 JAR 掃描 Bean 并按接口注入實現(xiàn)公共接口橋梁如何控制依賴方向并避免循環(huán)依賴整個過程可以概括為根 POM 聚合 → 子模塊聲明依賴 → Java 使用公共接口 → Spring 掃描實現(xiàn)類 → admin 統(tǒng)一裝配 → 運行時完成調用Maven 解決“編譯時能不能看見”Spring 解決“運行時由誰來實現(xiàn)”公共接口解決“依賴應該朝哪個方向”。三者缺一不可。當前進度[OK] 已經完成已完成主要模塊 POM 依賴方向的靜態(tài)核對已通過接口定義、實現(xiàn)類和啟動模塊還原聊天模塊與工作流模塊的協(xié)作關系[TODO] 后續(xù)繼續(xù)下一篇對比普通 CRUD 分層與 AI 對話編排分層繼續(xù)結合真實請求理解模塊協(xié)作在運行時如何落到方法調用小魚點睛Maven 解決“編譯時能不能看見”Spring 解決“運行時由誰來實現(xiàn)”公共接口解決“依賴應該朝哪個方向”。三者缺一不可。下一篇下一篇將繼續(xù)分析“AI 智能客服為什么不能照搬傳統(tǒng)三層架構CRUD 與 AI 編排分層對比”把本文建立的結構認知繼續(xù)落到具體代碼和對象流上。這篇文章是我在真實項目學習過程中的階段性記錄。不同項目的命名和目錄可能不同但判斷職責邊界、依賴方向和數(shù)據生命周期的方法可以復用。如果內容中還有遺漏歡迎一起交流。