01 / Bounded Context
系统边界先被切开，后续扩展才不会打结
认证、社交、旅行、AI、后台管理分别建模，再由 shared 提供数据库、事件总线和存储能力，说明它不是“把功能堆在一起”的课设。
- 用户、行程、社交、AI 的职责边界足够清楚。
- 后续演进时不需要把业务规则全部揉进一个模块。
- 对于招聘场景，这张图先回答“系统是怎么分块的”。
02 / Layered Design
应用层、领域层、基础设施层各自承担不同责任
Travel 模块不是直接从路由打到数据库，而是通过 TripService、聚合、仓储接口和 SqlAlchemy 实现分层协作。
- TripController 处理请求编排，不吞业务规则。
- Trip 聚合和 ItineraryService 承担核心领域逻辑。
- 地图服务和持久化细节被压在外层实现里。
03 / Social Domain
社交域覆盖动态、会话和好友关系三条主线
Post、Conversation、Friendship 三个聚合根支撑出动态广场、即时聊天和关系管理，而不是把所有互动都放进单一表结构。
- 帖子、消息、评论和值对象的关系一目了然。
- 分享、评论、聊天都能在同一个上下文内持续演进。
- 它说明这个项目的社交能力是被认真建模过的。
04 / Travel Domain
行程域把计划、活动、成员和路线统一进 Trip 聚合
Trip、TripDay、Activity 与 Transit 形成旅行计划的主模型，ItineraryService 负责路线与交通信息的协同计算。
- 活动、时间段、金额、位置都拥有独立语义。
- 多成员协作与活动编排不只是前端页面拼出来的状态。
- 这张图能直接支撑“行前规划”模块的讲解。
05 / Real-time Chat
即时聊天同时照顾了真值持久化与实时广播
消息先进入服务层完成持久化，再由 Socket.IO Handler 广播到会话双方；它不是轮询列表，而是一条完整的实时链路。
- 连接、入房、发送、写库、广播的顺序被明确画出。
- 实时体验建立在明确的服务与数据库协作之上。
- 对面试官来说，这比一句“支持聊天”更有说服力。
06 / AI Domain
AI 助手被单独建模成 app_ai 上下文
AiConversation、AiMessage、RetrievedDocument 与 MessageAttachment 共同构成 AI 会话能力，避免把模型调用直接塞进控制器。
- 会话、消息、附件与检索文档都有独立角色。
- ILlmClient 与 IRetriever 接口把外部能力隔离出来。
- 这样更适合持续替换模型或调整检索策略。
07 / RAG Pipeline
RAG 链路把检索、拼装 Prompt 和流式输出串成闭环
前端请求进入 Flask View 后，应用服务负责会话编排，领域服务执行检索与模型调用，再通过 SSE 把回答分段回送前端。
- Trips、posts、activities 都能成为检索素材。
- 不是一句“接了大模型”，而是完整的增强生成流程。
- 这张图把 AI 能力接入的工程细节讲清楚了。
08 / Persistence
AI 会话的数据层同样做了接口与实现分离
仓储接口、DAO 接口、持久化对象和仓储实现被拆成不同层，说明这个项目并没有把 AI 部分当成临时脚本来写。
- AiConversationPO 与 AiMessagePO 对应实际存储对象。
- DAO 与 Repository 分离让持久化逻辑更稳定。
- 它补足了“AI 功能可用”之外的工程可信度。
