高级 Java 与 AI 应用工程（六）：企业运营诊断 AI Copilot 架构

架构定位

本章以企业运营诊断 AI Copilot 为例，展示 Java 服务、DDD、消息、检索、LLM 工具调用、实时推送、工作流与 DevOps 如何形成一个完整系统。它不是特定业务的唯一实现，而是一份可用于架构设计和面试阐述的参考蓝图。

这个项目将 Java、Spring、DDD、Redis、RabbitMQ、Elasticsearch、工作流、LLM Function Calling、MCP、SSE、性能与 DevOps 串成一条完整链路。

高级 Java 与 AI 应用工程（二）：DDD、事件与分布式一致性

技术定位

DDD 不是将项目机械分为四个包，而是用统一语言和边界控制复杂性；分布式设计不是追求“最终一致”，而是在不能使用单一事务的地方，明确哪些结果必须立即一致、哪些结果可恢复地异步收敛。

1. DDD 解决的不是“代码分层”

DDD 的价值在于让业务概念和软件模型一致，降低规则散落在 Controller、SQL、定时任务和前端中的风险。先找业务语言，再决定类和表。

1.1 三个必须回答的问题

1. 这个系统的核心业务结果是什么？例如“报告已生成”而不是“数据库插入一行”。
2. 哪些规则必须始终同时成立？这决定聚合边界和事务。
3. 哪些变化可以接受最终一致？这决定事件、任务和补偿的边界。

概要

接手一个运行多年的企业级中台系统，面对的问题是：代码耦合严重、模块边界模糊、改一个功能需要理解整个系统。

经过半年的渐进式改造，我们完成了 DDD（领域驱动设计）四层架构的搭建，将"大泥球"拆分为通用模块、运营中心、全链路三个独立模块。本文记录了这个过程中的关键决策和实践经验。

改造前的状况

中台系统经过多年迭代，积累了大量技术债：

• 功能边界不清：不同应用间通过私有服务直接调用，没有登记到 API 中心，没有订阅关系，溯源困难
• 前端直调外部服务：绕过了中台网关，鉴权和限流形同虚设
• 存量功能维护成本高：改一行代码需要理解几千行上下文
• 技术架构不统一：开发人员不熟悉公共平台和框架，重复造轮