我那个 AI 导游小程序，是怎么烂成一锅粥的

去年我做了一个 AI 导游小程序。

想法挺好：用户打开地图，点一个景点，AI 给它讲段故事。再顺手把路线规划、门票、语音播报、社交分享全塞进去。

上线三个月，我就不敢动它了。

改一个景点的讲解逻辑，门票模块跟着崩。加个语音开关，分享功能开始报空指针。每次发版都像在拆炸弹。

后来我才懂：不是我代码写得差，是我从一开始就没想清楚东西该怎么切。所有逻辑揉在一个 Service 里，一个类八百行，谁也讲不清哪段属于哪块业务。

这事儿如果用两套思维重新审视，能看得特别透。一套管”业务怎么建模”，一套管”架构怎么让人看懂”。

第一套：DDD，先想清楚边界

DDD（领域驱动设计）最反直觉的一点——它不急着让你写代码，先让你划地盘。

边界比功能重要

同一个词，在不同地方意思完全不同。

在我的小程序里，”景点”在讲解上下文里是一段文本 + 坐标，在路线上下文里是一个需要计算时间的节点，在门票上下文里是一个要查库存的商品。

我当时用一个 ScenicSpot 对象硬撑全场。结果讲解要加字段，门票逻辑被带歪；路线要改结构，讲解跟着报错。

DDD 管这叫限界上下文：每个上下文有自己的模型，别用一个万能对象糊弄所有场景。

聚合根：一致性守门员

我踩的最大的坑，是把”用户、订单、景点、路线”全塞进一个聚合，谁都能改谁。

DDD 说：一个聚合只能有一个根，外部只能找根办事。想改景点讲解？走景点聚合根。想改订单状态？走订单聚合根。跨聚合的事，用领域事件松耦合地传，而不是一把大锁锁死全表。

一句话：聚合根划小了，系统才敢改。

统一语言：别各说各话

最贵的 bug 往往不是代码错，是”你说的订单和我说的订单不是一回事”。

DDD 的魂是统一语言——产品、开发、业务坐一桌，用同一套词，而且这词直接写进类名、方法名。需求变了，语言变，模型变。

这才是”领域驱动”，不是”数据库驱动”。

第二套：4+1 视图，让架构被人看懂

代码写完只是 half。另一半是：怎么让不同角色的人看懂它在怎么跑。

Philippe Kruchten 的 4+1 视图，干的就是这事。

那 “1” 是场景

一个关键用例，比如”用户点景点→AI 讲解播放”。拿它当红线，把下面四个视图全串一遍，证明架构真能跑通。没有场景，视图就是 PPT。

那 “4” 是四拨人各自的视角

• 逻辑视图：业务方看。系统做什么？功能怎么拆成模块。
• 进程视图：性能工程师看。并发、线程、同步怎么组织。
• 开发视图：写代码的人看。代码怎么拆组件、怎么编译。
• 物理视图：运维看。软件跑哪台机器、节点怎么连。

我当年那张”架构全景图”为什么没人看？因为我把四拨人的事塞一张图里，谁都看不清自己那层。

4+1 的哲学很简单：架构不是一张图，是多个正交视角，场景是校验它们的胶水。

DDD 和 4+1，其实是一伙的

很多人以为 DDD 管建模、4+1 管架构，是两码事。

错了。DDD 的限界上下文，天然就是逻辑视图里的模块边界。而 4+1 的物理视图、进程视图，正好补上 DDD 几乎不碰的”部署与并发”——两者拼起来，才是一个能写、能跑、能讲清楚的完整系统。

我那小程序要是早懂这两套，至少能少加三个月班。

一句封喉

混乱不是因为代码多，是因为没人划清”哪块归哪块”。DDD 划业务的边界，4+1 划认知的边界——边界感，才是架构师的底层能力。

如果你也在带一个越改越怕的项目，先别急着重构代码，先拿张纸把边界画出来。