最近几个月我被问得最多的一个问题就是AI都能自动写代码了DDD领域驱动设计这套东西是不是该进垃圾桶了每次听到这种论调我都能想起去年做AI Agent项目时的经历——团队一开始觉得有大模型就万事大吉结果工程越做越失控提示词越来越长消息越攒越碎模型行为飘忽不定业务方也完全看不懂系统该怎么演进。后来我们回头把领域边界重新梳理了一遍问题才逐渐收敛。今天不打算讲空泛的架构趋势就聊聊我在这类项目里的实际观察和踩过的坑顺便把“AI时代是否还需要DDD”这个老问题从实操层面重新拆一遍。先说结论DDD非但没过时在AI时代反而更值钱了。但值得注意值钱的不是那些表格、仓库、实体的套路而是它思考问题的方式。这个结论不是我坐在电脑前拍脑袋想出来的是从几个真实项目的血泪史里总结出来的下面慢慢讲。1. AI时代DDD被质疑到底在质疑什么1.1 “AI写代码”让建模这件事看起来很多余大家质疑DDD的第一直觉是“AI都能写代码了为什么还要花几周画领域模型、开事件风暴”。这个思路我能理解。当你看到大模型噼里啪啦生成一整套CRUD代码甚至能帮你把controller/service/repository一条龙写完时确实会产生一种“传统软件工程方法论已经失效”的错觉。但这里有个严重的偷换概念AI能生成代码不等于AI能理解业务。打个比方一个实习生打字再快也不能替代产品经理把需求想清楚。大模型本质上是一个极其擅长“把输入映射为输出”的机器它可以在你给出清晰边界和规则时把类、接口、测试写得又快又好。可一旦边界本身模糊、业务规则互相矛盾大模型不会帮你指出这些问题它会很自然地顺着你糟糕的指令生成一套同样糟糕的代码然后看起来还挺像那么回事。所以AI时代最稀缺的不是“写代码的能力”而是“定义问题的能力”。DDD从头到尾干的就是这件事——它逼着业务方和开发团队把问题空间捋清楚把业务规则显性化把模糊的需求翻译成准确的模型。这个能力和AI出现之前相比不是变轻了而是更重了。1.2 “AI Agent自治”让传统分层看起来很笨重第二个质疑点更技术化AI Agent的决策过程是动态的、非确定性的它会自己规划步骤、调用工具、根据环境反馈调整行为。这种“苗条”的工作方式和传统DDD那套“严格分层、领域服务封装、仓储抽象、聚合设计”放在一起总感觉格格不入。有些做AI应用的朋友跟我说Agent的核心逻辑就是一条决策链加一堆工具调用再搞领域模型反而碍手碍脚。这个质疑有合理成分但它混淆了两个层级的问题。Agent的“决策编排”确实可以是轻量灵活的它相当于一个大脑在实时做路由可是这个大脑要做出正确决策必须建立在“对世界足够清晰的结构化认知”之上。什么叫清晰的结构化认知就是系统知道什么是订单、什么是支付单、什么是库存预占知道这些概念之间的业务规则是“先校验库存再创建订单”而不是“直接调一个保存接口”。如果你没有领域模型Agent面对任何请求都是从零开始猜。它猜对了算运气好猜不对你根本无从排查。因为整个系统里没有一个稳定、可校验、可审计的领域骨架。我在一个电商售后项目里就见过这种情况Agent要处理退货退款它需要调用售后单、订单、支付流水三个系统的能力。没有领域边界时Agent反复横跳一会儿把支付流水的状态当成订单状态用一会儿把退货单的金额搞错。后来我们做的事情其实很DDD界定每个子域梳理聚合把Agent可能触发的业务动作都收敛成领域服务。结果非常明显Agent的准确率直线上升。1.3 “上下文窗口”成为新的稀缺资源还有一个比较隐蔽的困惑值得单独拎出来说。很多团队发现大模型上下文窗口有限没法把整个业务全量塞进去。于是大家想尽办法做RAG、做摘要、做记忆压缩但效果常常不尽人意。其实这里遇到了一个本质问题内容边界没划清。你不知道哪些知识属于这个场景、哪些不属于神经网络再会“理解”也没法替你决定知识边界。DDD里的“限界上下文”这个概念恰恰就是用来划分知识边界的。每个上下文内只能有自己职责相关的模型上下文之间通过明确接口交互。把这个思路搬到AI架构里正好可以决定每个Agent的上下文窗口里该灌注什么知识、不该放什么内容。上下文边界清晰了窗口再小也够用边界混乱给你一个亿token的窗口也白搭。2. AI友好型架构真正要解决的是边界问题2.1 从“限界上下文”到“AI上下文”很多AI应用团队问我AI友好型架构到底长什么样。我说先别急着上框架先把边界找出来。传统分布式系统里我们用限界上下文管理“团队之间的语言边界”和“服务之间的数据边界”。到了AI时代这件事演化成了三个层面的边界管理第一层是知识边界哪个模型负责处理哪类领域知识哪些背景知识需要进入Prompt哪些知识必须从外部检索注入。这层边界如果不清会出现一个很尴尬的场景你往Agent里塞了一堆无关文档它答什么都绕关键问题反而记不住。第二层是行为边界Agent能做哪些事、不能做哪些事。这个必须在架构层面定义清楚不能指望模型“自觉”。比如一个客服Agent哪些动作允许它直接执行查订单状态、改收货地址哪些动作必须人工审批退款、补偿。这类行为边界的背后其实就是DDD里“领域服务”和“应用服务”的职责划分。第三层是数据边界Agent可以读写哪些数据不可以碰哪些数据。这已经不是权限控制的细粒度问题而是模型如何理解数据所有权和一致性的问题。没有数据边界模型就可能把一个领域的半成品数据当成另一个领域的输入。我见过不少AI项目哭天喊地说大模型效果不行其实问题根本不在模型而是三个边界一锅粥。知识边界、行为边界、数据边界混在一起提示词写得再花哨也救不回来。2.2 上下文窗口与内聚的聚合模型DDD里有个概念叫“聚合”说的是把一组强一致性的对象打包在一起外部只能通过聚合根访问它们。这个概念放在AI时代特别有意思——它基本回答了一个经典难题该往Prompt里放什么、放多少。很多团队在做RAG时恨不得把企业知识库的一半文档都灌进去结果检索质量崩塌。如果按聚合的思路组织知识一个聚合对应一个完整的业务处理单元聚合根就是入口。检索时只补充聚合根能定位到的最小知识包而不是把整个数据库倒进去。你会发现Prompt变短了、回答变准了、幻觉明显减少。为什么因为知识的“内聚性”变强了模型拿到的是一个有完整语义边界的知识块而不是碎片拼接。2.3 事件风暴在AI Agent设计中的应用事件风暴是DDD建模的一种高效工作坊形式大家一起贴着业务事件捋流程。我在AI项目里发现事件风暴依然是最好用的架构分析工具不过风暴的对象变了不再只是“用户下单”这类业务事件还要加入“模型判断”“工具调用”“执行结果反馈”“异常重试”这类AI行为事件。为什么要这么干因为AI Agent本质上是一个高度事件驱动的系统。用户说了一句话这是一个输入事件Agent决定调用搜索工具这是一个决策事件工具返回结果这是一个结果事件Agent发现结果不满足约束触发重新规划这又是一个重试事件。把这些事件完整建模Agent的可观测性、可恢复性、可测试性才有着陆点。我在一个AI数据分析助手项目中就用事件风暴的方式跑了一遍完整的Agent决策链路。结果发现大家吵了半天“这个Agent应该怎么回答”其实根源是对“回答前的分析过程应该走哪几步”没有统一认知。事件风暴一跑每个人都能看到事件序列里的断裂点问题立刻浮出水面。3. 实操如何用DDD的思路构建AI友好型架构3.1 按限界上下文拆分AI Agent的职责先给一个直接可用的实操原则一个限界上下文对应一组职责内聚的Agent能力而不是一个Agent干所有事。具体落地时我习惯先把业务域按DDD战略设计的方式拆出子域再为主题域设计对应的Agent。举个例子一个企业级智能客服系统可以拆出这些子域用户画像域负责识别用户身份、历史偏好、会员等级订单域负责查订单、改地址、催物流售后域负责退货退款申请、进度查询知识问答域负责FAQ、产品帮助文档、政策解释每个子域都可以有一个独立的Agent它们各自拥有自己的Prompt、工具集、记忆库。用户会话进来后由一个编排Agent或者路由模型判断当前意图属于哪个子域再分发给对应的Agent处理。这套方案有几个直观的好处提示词天然变短因为每个Agent只需关心自己子域的知识模型切换成本降低某个子域升级模型只影响局部问题排查也简单边界清晰后你一眼就能看出是哪个Agent的环节出了错。3.2 防腐层隔离LLM与业务系统DDD里有个模式叫防腐层Anti-Corruption Layer专门用来隔离外部系统的概念污染。这个模式在AI架构里价值极大。大模型的输出天然不可控格式不稳定偶尔还会出现幻觉。你不可能让这样一个不稳定的外部组件直接碰你的核心领域模型。正确做法是大模型返回的原始输出先进防腐层在里面做格式校验、字段映射、领域规则校验然后才转换成领域模型。防腐层里还可以内置数据兜底逻辑模型说“订单已发货”但它把订单状态映射错了防腐层要能发现异常并拒绝或纠正。我在实现一个票据自动处理Agent时就让模型直接输出JSON格式的结构化提取结果。原始输出里偶尔会出现字段错位、枚举值不合法、甚至金额对不上号。防腐层的职责就是把这些错误全部拦住——JSON校验不通过就重试枚举值不合法就用规则修正金额对不上就转人工。如果没有这一层脏数据会直接污染下游财务系统。防腐层还有一个隐藏作用它是模型升级的缓冲垫。今天用GPT-4o明天想换Qwen只要防腐层的契约接口不变切换模型的成本就极低。这跟六边形架构里的端口适配器思想完全吻合。3.3 事件驱动让Agent决策具备可追溯性很多AI Agent项目最大的痛不是“答不对”而是“不知道为什么答成这样”。传统调试靠日志AI调试更大程度上依赖决策链路还原。没有事件驱动的架构设计这一步几乎做不了。我建议在Agent流程里显式引入领域事件并且把事件全部持久化。事件模型分两层业务事件订单已支付、退款已发起、库存已锁定。它们是系统对外承诺的真实事实。决策事件模型选择调用了某工具、模型生成了某个中间计划、模型判定需要人工介入。它们是AI推理过程的行为记录。这两层事件分开记录排查问题时的体验完全不一样。业务事件告诉你系统承诺了什么决策事件告诉你AI为了达成承诺做了哪些尝试。两者对照很容易定位“承诺了没做到”或“做到了但承诺错了”的根本原因。举一个实际案例Agent在处理退款时误把1000块退成10000块。光看业务日志只能看到退款已发生但不知道为什么会发生。往前翻决策事件就能看到模型在某个中间步骤把“商品原价”误当成了“退款金额”根源立刻清晰。这种排查能力在传统系统里需要事件溯源架构在AI系统里几乎是刚需。3.4 六边形架构把AI能力当成外部端口很多做DDD的人对六边形架构也不陌生。它强调核心业务逻辑居于中心外部技术细节通过端口和适配器接入。AI时代这个原则依然适用只要你愿意把大模型、向量数据库、外部工具都当成“外部适配器”。核心领域层不该直接依赖OpenAI SDK或者某个向量库的客户端。应该定义“模型网关端口”由适配器实现具体的模型调用定义“检索端口”由适配器实现向量库检索或关键词搜索。这样做的好处是你的领域逻辑可以纯本地单测不需要连接任何付费API模型调用失败、超时、限流在适配器层就可以做降级和重试不会污染核心逻辑。有人觉得这是过度设计但AI基础设施变化太快了。你今天用的框架、模型接口半年后可能就是遗留技术。把不稳定的一切都收敛到适配器层才能让核心领域逻辑稳定地迭代下去。这种“稳定内核 不稳定外围”的结构其实就是AI友好型架构最务实的一种解释。4. 哪些DDD遗产必须保留哪些需要主动调整4.1 战略设计可以全盘保留它解决的是复杂度问题先说结论战略设计层面限界上下文、上下文映射、子域划分在AI时代完全是核心竞争力。原因不复杂AI系统比传统系统更容易产生混沌因为多了一个不受控的模型参与者。越是混沌的环境越需要清晰的边界。所以我建议所有AI应用团队尤其是涉足复杂业务领域的团队一定要做战略设计。哪怕不叫DDD也要把“子域划分”“上下文边界”“上下文之间的集成方式”这些事踏踏实实做完。4.2 战术设计要“挑着用”避免过度建模战术设计实体、值对象、聚合、领域事件在AI场景里需要做一些调整。传统的战术设计假设所有规则都写死在代码里由人保证一致性和并发安全。AI场景里部分规则的逻辑起点来自模型输出这些输出本质上更多是“建议和预测”而不是“精确指令”。在规则驱动的稳定领域比如资金计算、库存扣减、价格核算战术设计照用不误——这些环节容不得模型自由发挥必须由确定性代码掌控。模型可以做判断但最终执行必须落在确定的聚合和领域服务上。在交互和理解驱动的环节比如意图识别、话术生成、摘要生成战术设计只需要保留一些轻量数据结构不必强上聚合根和仓储。用一个简单的策略对象或者值对象接住模型的输出然后交给防腐层去转换。一句话总结我的取舍原则战略设计重兵投入战术设计精准投放追求稳定性的核心链路绝不交给模型自治追求灵活性的认知链路绝不交给僵硬编码。4.3 别再为了DDD而DDD也别因为AI而废DDD有些团队以前就没把DDD做好但至少是在努力建模。现在有了AI干脆连建模都不建了觉得“模型会自己理解需求”。这是从一个极端跳到另一个极端。反过来也见过团队在AI系统里硬套全套DDD。为了幂等去设计复杂的仓储为了聚合硬造一堆对象结果Prompt生成的流畅交互被这些重逻辑拖累。DDD是手段不是目的AI时代更要克制。我的建议很简单回到问题空间。如果业务本身不复杂就是一个简单的CRUD加几个AI辅助功能没必要上领域模型。如果业务复杂、规则繁重、多方协作链路长那不管有没有AI都需要DDD式的设计。AI只是改变了实现方式没有改变业务复杂度的本质。5. 常见问题与排查技巧实录5.1 AI响应不稳定导致业务状态混乱怎么办现象Agent调用了创建订单的服务但模型输出的参数缺了一个必填字段导致系统落库失败或者落了一个错误的订单状态。排查思路不要指望模型永远输出正确参数。在防腐层做全字段约束校验失败则重试一次仍然失败就转人工工单。同时在事件模型里记录“调用失败次数”和“失败原因”方便后续优化提示词或者模板。我的实操技巧给模型设计结构化输出模板JSON Schema模板字段直接对应领域服务的入参。这样从源头上减少漏参数的概率。如果某个字段非常关键建议在防腐层再做一次硬校验宁可多跑一道校验不让脏数据漏到核心领域。5.2 上下文窗口太小模型无法理解全局怎么办现象业务链路很长单个Agent的Prompt里放不下完整业务流程说明。塞多了爆窗口塞少了模型乱猜。排查思路不要试图让一个Agent理解全部业务。按限界上下文拆分子域Agent每个Agent只承担自己上下文的职责。跨上下文的事务通过编排层比如一个总控Agent来路由和组合结果。这样每个Agent的上下文窗口只装自己那部分知识空间自然就够用了。另外用“聚合”的思路设计记忆和检索。不是把所有历史消息都喂给模型而是提炼成“聚合摘要”当前上下文内核心事实是什么、关键约束是什么、未完成的事项是什么。这样记忆轻装上阵效果反而更好。5.3 团队觉得DDD太重在AI项目里不想用怎么办现象团队以前被DDD的各种术语和仪式吓怕了一听要“事件风暴”就抗拒。排查思路换个说法不叫DDD叫做“把AI系统的边界梳理清楚”。组织一场“AI系统功能沙盘推演”让业务方和技术方一起把AI能力能做什么、不能做什么、需要哪些数据、产出哪些结果列成事件清单。实操下来这就是一次轻量版事件风暴但不用术语包袱。我反复强调DDD的精髓不是名词体系而是它背后的思考顺序——先界定问题空间再设计解决方案空间。AI项目尤其需要这个顺序因为模型的加入会让“解决方案空间”看起来无限大反而容易让人忘记“问题空间”里的真实约束。6. 我个人在这段时间实操里的几点体会做AI项目这段时间我最大的体会是架构师的工作不是被AI取代了而是变重了。过去架构师还要担心数据库范式、缓存一致性现在这些工作很多被框架和AI工具替代了。但架构师真正的核心工作——识别业务本质、划定领域边界、确保模型在边界内行事——反而成了决定AI项目成败的关键。我自己在项目里使用频率最高的可能不是某个提示词技巧也不是某个框架的API而是那一套反复问自己的老问题这个领域里到底有哪些核心概念它们之间的关系是什么哪些规则是雷打不动的硬约束哪些环节可以让模型自由发挥这套问题本质上是DDD在问的问题。所以回到标题AI时代我们还需要DDD吗我的答案非常明确——需要而且比任何时候都需要。只不过我们需要的是那个“看清问题空间”的DDD而非“堆砌类与层”的DDD。最后再分享一个小技巧如果你的团队正在做一个AI应用别急着写代码先花半天时间白板上把事件流画一遍。用户进来了发生什么事件Agent要做什么决策需要调用哪些领域能力哪个边界上允许模型自主发挥哪个边界上必须人来做决定这张图就是AI友好型架构的第一份核心资产也是DDD在AI时代最有价值的呈现方式。