AI 编程时代 DDD 的理论重估：一种面向复杂业务与生成式智能的建模语言

AI 编程时代 DDD 的理论重估：一种面向复杂业务与生成式智能的建模语言

------兼论从微服务架构知识到 AI 约束语言的范式迁移

作者：少林猿

日期：2026-05-02

摘要

在生成式 AI 广泛介入软件开发之后，关于领域驱动设计（Domain-Driven Design, DDD）是否仍然必要的争论重新浮现。本文并不把 DDD 仅仅视为"微服务时代的遗产"，而是将其重构为一种面向复杂性的认知与建模方法：它通过统一语言、限界上下文、实体、值对象、聚合、领域事件等概念，将模糊业务知识转化为可讨论、可约束、可验证的结构化表述。本文采用规范分析与文献综述相结合的方法，以 Eric Evans 的原始 DDD 论述、Martin Fowler 对战略设计与统一语言的阐释、OpenAI 的 Model Spec、GitHub 的 Spec-Driven Development 工具链，以及关于 LLM for Software Engineering 与 promptware engineering 的研究为基础，论证 AI 编程时代的核心矛盾已从"生成代码"转向"约束输出、表达边界与维持业务一致性"。文章指出：DDD 对 AI 开发的价值并不直接来自 AI 本身，而来自复杂业务系统中长期存在的语义歧义、边界冲突与一致性约束；AI 只是把这些问题以更高频率、更低门槛的方式放大了。基于此，本文进一步提出一个面向 AI 编程的 DDD 解释框架：DDD 作为需求规范、上下文治理与生成约束的统一语法，可与规范驱动开发、提示词工程和智能体编排形成互补关系，但其适用性仍以领域复杂度为前提，而非所有 AI 项目的普遍前提。

关键词： 领域驱动设计；生成式 AI；规范驱动开发；统一语言；限界上下文；promptware；软件工程

一、问题的提出：从"微服务时代的 DDD"到"AI 时代的 DDD"

在过去十余年的工程实践中，DDD 常常与微服务架构绑定出现：它被当作一种用于拆分服务、管理边界、设计聚合和控制事务的一整套后端架构方法。这种理解并非错误，但它过于狭窄。DDD 的原始目标从来不是服务拆分本身，而是将复杂业务域中的知识、语言和规则组织为可协作的模型。Evans 在《Domain-Driven Design》中强调的，是把软件开发对准领域模型，而不是把软件对准某一种部署形态。Martin Fowler 也明确指出，DDD 的战略设计关心的是如何把大模型分解为多个限界上下文，并清晰描述它们之间的关系。

当生成式 AI 进入开发流程后，问题发生了结构性变化。AI 让"写代码"变得更快，却并没有自动消除"知道该写什么、如何不写错、如何让不同角色对同一对象说同一种话"这些更根本的问题。事实上，LLM 在软件工程中的应用越广，越会暴露出需求歧义、规范缺失、上下文漂移和幻觉输出等老问题。相关综述指出，LLM 已经渗透到编码、设计、需求、修复、重构、文档与分析等多个软件工程环节，但可靠性、基准评估和领域定制仍是主要挑战。

因此，本文的中心命题是：DDD 在 AI 编程时代的重要性并非来自 AI 本身，而是来自复杂性这一更深层的工程事实。AI 只是让复杂性的后果更快显现、更难隐藏。如果说微服务时代要求开发者学会如何切分系统，那么 AI 编程时代则要求开发者学会如何把系统的边界、术语与不变量说给机器听。DDD 正是在这条路径上仍然具有高解释力的方法论。

二、理论基础：DDD 不是技术栈，而是复杂领域的知识组织法

DDD 的概念体系通常被分成战术设计与战略设计两层，但真正决定其生命力的，是战略设计。战术层面的实体、值对象、聚合与领域服务固然重要，但这些概念最终都服务于一个更高层的目标：在复杂业务中建立稳定的语义秩序。Fowler 对 DDD 的总结指出，它是围绕"具有丰富业务过程与规则理解的领域模型"来展开的软件开发方法。换言之，DDD 并不是在代码层面发明一组时髦术语，而是在建模层面提供一套足够精确的认知工具。

统一语言（Ubiquitous Language）是这一工具箱的中心。Fowler 明确将其定义为开发者与使用者之间建立的共同而严格的语言，并强调这门语言必须依托软件中的领域模型，因为软件无法容忍含混。这一判断在 AI 时代反而更具现实意义：LLM 的强项在于生成关联，而弱项恰恰在于对语义边界的自发澄清。当术语缺乏明确约束时，模型可能生成看似合理却在业务上错位的内容。由此可见，统一语言不是可有可无的文档修饰，而是减少语义漂移的基础设施。

限界上下文（Bounded Context）是 DDD 战略设计的另一根支柱。Fowler 明确指出，它是 DDD 战略设计的中心模式，核心任务是处理大模型和团队问题。这意味着：在一个足够复杂的领域里，同一个词语在不同子域中的含义可能并不一致，因此必须把模型放在边界之内理解。从哲学上说，限界上下文并不是把世界切碎，而是承认"意义总是在语境中成立"。从工程上说，它防止了模型膨胀成没有边界的抽象集合，也防止团队在隐含语义冲突中不断返工。

进一步地，聚合与领域事件提供了局部一致性与过程可追踪性的机制。聚合把关键业务不变量封装在事务边界内，确保外部只能通过聚合根修改系统状态；领域事件则把已发生的领域事实显式化，使系统能够围绕事实而非意图进行协作。这两项机制的共同点是：它们都在对抗复杂系统中最常见的失败模式------隐式规则、跨边界修改和状态失控。因此，DDD 的本质不是"用对象包装业务"，而是"把业务中的不可妥协之处显式化"。

三、AI 编程时代的结构变化：代码生成不再是中心问题

传统软件开发的核心瓶颈通常在于实现成本：知道问题、设计清楚之后，写出代码仍需要投入显著的人力。AI 编程大幅压缩了这一阶段的成本，因此真正的瓶颈迁移到了"前置知识表达"和"后置结果约束"上。OpenAI 在 Model Spec 的说明中明确强调，模型行为需要被定义、讨论和评估，并且这种规范是面向未来持续演化的。这表明，即便在最先进的模型体系中，单纯依赖概率生成并不足以满足可控性要求，必须借助显式规范来界定行为。

GitHub 的 Spec-Driven Development 工具链进一步说明，规范不再只是文档性的说明，而可以成为生成实现的核心中介。其公开说明直言，规范在新的开发范式中从"脚手架"转变为"可执行的输入"。这类实践虽然并不自动等同于 DDD，但它们共同预示着同一个趋势：软件开发正在从"以代码为中心"转向"以可审查规范为中心"。在此背景下，DDD 的价值不在于替代规范驱动开发，而在于为规范提供能落地到业务复杂性的概念语法。

关于 LLM 在软件工程中的研究也支持这一判断。多篇综述性论文指出，LLM 已被用于多类软件工程活动，但同时伴随幻觉、不可靠性、领域偏差、评估困难与安全问题。换言之，AI 编程并没有消灭软件工程的经典难题，而是把这些难题前移到需求、语义和约束层。在这样的范式中，越是复杂的领域，越需要清晰的边界和严格的语言；否则，AI 产生的并不是"更聪明的软件"，而是"更快生成的混乱"。

四、为什么 DDD 在 AI 时代重新变得重要：复杂性而非 AI 才是根因

必须强调，DDD 的重要性并不来自 AI 的出现本身，而来自复杂性本身。如果一个问题足够简单，使用表单、脚本或 CRUD 服务就能解决，那么 DDD 往往只是增加认知成本，而不是降低它。只有当系统同时满足以下条件时，DDD 的收益才会显著上升：业务规则密集、术语歧义高、跨团队协作频繁、生命周期长、以及不同子域之间存在实质性的语义冲突。这也是为什么 DDD 通常更适合金融、保险、供应链、医疗、政务、平台交易与大型企业中台，而不适合所有轻量应用。

从认识论角度看，复杂领域的困难并不只是"知识很多"，而是"知识彼此之间需要协调"。领域专家往往在口头上知道规则，但规则并未被形式化；开发者往往能写出逻辑，但不知道业务语义的优先级；AI 则可以快速生成实现，却无法天然判断业务边界。DDD 正是把这三者连接起来：统一语言帮助知识显性化，限界上下文帮助知识分区，聚合帮助知识落在不变量上。因此，DDD 的角色更像一套"复杂知识的压缩编码法"，而不是某个时代的编程潮流。

这一点也解释了为什么 DDD 在 AI 场景中会显得更重要。因为 AI 擅长从上下文中补全，而复杂业务恰恰要求上下文被精确给定。如果上下文不清，模型会"合理化"错误；如果边界不清，模型会跨域混合语义；如果不变量不清，模型会在生成中引入违反业务规则的状态。因此，AI 时代的 DDD 不是"为了微服务而拆服务"，而是"为了让机器能正确理解并受约束地执行领域规则"。

五、DDD 与 AI 开发范式的耦合：从统一语言到规范驱动

DDD 与 AI 开发的耦合点，首先体现在统一语言与提示词工程之间。提示词工程的本质并不是"写更长的 prompt"，而是通过更明确的任务定义、上下文组织与输出约束，提高模型行为的一致性。这与统一语言的目标高度一致：都要求把概念、边界和规则说清楚，避免语义漂移。不过，二者的层级并不相同。提示词工程偏向局部交互与即时输出，统一语言则是长期、组织级的语义治理。

其次，限界上下文与智能体编排之间存在天然同构。一个成熟的多智能体系统不应让每个 Agent 都理解全部业务，而应让每个 Agent 在清晰边界内拥有专门职责。这正对应限界上下文的设计思想：不同上下文可以拥有各自的模型、术语与规则，并通过明确的映射关系进行协作。在这个意义上，DDD 并不是把 AI 直接变成软件架构，而是为 AI 协作提供了边界划分的原则。

再次，聚合与生成式修改之间存在关键的约束关系。AI 很容易生成"看起来合理"的跨对象修改，但真正的业务系统需要保证状态演化满足不变量。聚合的价值就在于把这种不变量设计为结构的一部分，而不是事后补丁。这意味着，AI 在执行 CRUD、状态变更、审批流或订单流时，必须被限制在聚合边界内进行操作，否则系统会出现局部正确、整体错误的情况。

最后，领域事件为 AI 驱动的流水线提供了事实驱动的协同机制。与其把 Agent 之间的协作理解为"任务接力"，不如将其理解为"领域事实的连续生成与消费"。这样做的好处在于：AI 不再依赖隐式会话记忆，而依赖可追踪的业务事件；不再依赖个体推断，而依赖组织化的事实流。因此，DDD 可以成为 AI 时代的元语言，但前提是我们承认它的作用对象首先是领域复杂性，其次才是模型。

六、理论边界与批判：为何不能把 DDD 神化为 AI 时代的万能钥匙

任何严肃的理论重构都必须讨论边界。第一，DDD 的适用前提是复杂领域。如果业务规则极少、边界清晰、变化频率低，过度引入 DDD 反而会形成"建模过度"的成本。因此，DDD 的正确定位不是普适技术，而是高复杂度情境下的高价值方法。

第二，DDD 不能替代验证。即便拥有统一语言和良好的限界上下文，AI 仍然可能在局部生成不符合事实的内容。OpenAI 的 Model Spec 和软件工程领域的综述都提示：仅靠生成机制无法根除错误，仍需评估、审查与反馈回路。所以，DDD 只是把错误更早暴露、更清楚表达，而不是自动消除错误。

第三，DDD 不能自动转化为生产力。DDD 的组织成本并不低，它要求领域专家持续参与、团队共享术语、架构师保持抽象克制，并且在演化中维护模型一致性。在缺乏这种组织条件时，DDD 容易沦为术语堆砌。这也是为什么一些项目"学习了 DDD"，却没有真正得到 DDD 的收益。方法论是否有效，不取决于名词是否高大上，而取决于组织是否愿意为清晰性支付成本。

第四，AI 并不会自动理解 DDD。如果只是把 DDD 概念写进 prompt，却没有将其转化为结构化规范、约束与测试，模型仍然会按概率模式自由发挥。因此，真正有效的路径不是"给 AI 贴 DDD 标签"，而是把 DDD 的概念实体化为可以验证的中间产物，例如领域词汇表、上下文地图、事件列表、聚合规则、状态机、验收标准和测试用例。也就是说，DDD 对 AI 的价值在于可操作化，而不在于口号化。

七、一个可操作的学术命题：面向 AI 编程的 DDD 重释框架

基于以上讨论，本文提出一个可操作的重释框架：在 AI 编程时代，DDD 可被理解为"业务复杂性的语义压缩与生成约束框架"。这个框架包含四个连续层次。

第一层是语义提取层。通过事件风暴、访谈、示例场景与术语对齐，将隐性的业务知识提炼为可共享的概念集合。这一层的产物不是代码，而是"领域语言的清单"。

第二层是边界建模层。将概念划分到不同限界上下文，并明确上下文之间的关系，包括共享内核、客户-供应商、反腐层、顺从者等典型模式。这一层的产物是"系统边界的地图"。

第三层是不变量约束层。围绕实体、值对象、聚合与领域事件，将核心业务规则变成可执行的约束。这一层的产物是"系统不会轻易犯错的规则"。

第四层是生成协同层。把前述三层产物转化为可供 AI 消费的规范文档、提示模板、测试标准和审查清单，从而让 AI 在约束中生成实现。这一层的产物是"机器可理解的操作协议"。

这一框架的关键结论是：DDD 并不是 AI 的替代品，而是 AI 的前置条件之一，尤其在复杂业务中如此。没有 DDD，AI 仍然可以写代码；但没有 DDD，AI 更难稳定地写出符合复杂业务逻辑的代码。这正是"DDD 不是微服务旧知识，而是面向复杂性的通用方法论"的理论含义。

八、结论

本文从理论与文献两条路径证明：在 AI 编程时代，DDD 的价值并未衰减，反而在复杂业务场景中显著上升。但这种上升并不是因为 AI 本身神奇，而是因为 AI 将软件开发中长期存在的复杂性问题放大并前置：术语歧义更容易暴露，边界冲突更容易蔓延，不变量更容易被破坏，缺少规范的系统更容易被"高效率地错误生成"。因此，DDD 的现代意义不应被简化为微服务拆分术，而应被重估为一种面向复杂性、边界与语义治理的建模语言。它与规范驱动开发、提示词工程和多智能体协作并不冲突，反而能为这些范式提供最重要的前提：清晰的领域语言、明确的边界与可审查的不变量。从这个角度看，AI 编程时代真正需要的不是"抛弃 DDD"，而是把 DDD 从后端架构实践提升为组织级知识工程。

与之相对，若把 DDD 简化为"给 AI 多喂一些业务术语"，则会落入概念主义陷阱。DDD 之所以有价值，不是因为它提供了一串名词，而是因为它把名词放进了可协作的结构：上下文、聚合、事件、边界、关系与一致性。一旦这种结构被抽空，DDD 便不再是理论，而只剩修辞。

八、与相关范式的比较：DDD、规范驱动开发与提示词工程

DDD 与提示词工程的关系也应当被重新理解。很多团队把提示词工程当作一次性技巧，但在复杂业务中，真正有效的提示并不是"写得更聪明"，而是"写得更结构化"。统一语言、边界定义和不变量说明，能够把提示词工程从经验型操作提升为可复用的组织能力。

DDD 与规范驱动开发（Spec-Driven Development）最重要的关系，不是替代，而是层次互补。规范驱动开发强调在编码之前建立可执行、可追溯的规范；DDD 则回答这些规范应该围绕什么来组织。前者偏向流程控制，后者偏向概念建模；前者解决"如何让实现遵循规范"，后者解决"规范本身应该如何表达业务复杂性"。

这种方法的优点在于，它能够避免把短期工具趋势误判为长期理论结构。AI 领域的工具层变化极快，但复杂系统中围绕边界、语义与一致性的基础问题变化较慢。从学术上讲，只有把这两者分开，我们才不会把"某一代工具能做什么"与"某一类复杂性需要什么"混为一谈。

更具体地说，本文试图回答三个理论问题：第一，DDD 的核心价值究竟来自微服务，还是来自复杂性；第二，AI 编程改变的是代码生产方式，还是需求表达方式；第三，DDD 是否可以被视为 AI 开发中的一种语义治理框架。围绕这些问题，本文主要依赖经典文献、厂商规范文档与近年的综述性研究进行交叉论证。

九、研究方法的自我说明：为何本文采用规范分析而非经验回归

本文选择规范分析与文献综述相结合的方法，而不是直接做经验回归，原因在于本文讨论的对象首先是概念边界与理论位置，而非某个单一工具的性能对比。DDD 的适用性并不能仅通过一组基准测试直接判断，因为它解决的是"如何组织复杂知识"的问题，而这个问题具有显著的语境依赖性。

十、对实践者的三条建议

第一，先做语义资产盘点，再做代码生成。任何希望让 AI 进入复杂业务系统的团队，都应先建立领域词汇表、上下文地图、核心事件清单和不变量清单。这些产物不一定一开始就完美，但它们必须先于自动生成而存在，因为它们决定了模型会在什么语境中工作。

第二，把 DDD 产物写成可执行规范，而不是停留在幻灯片或会议纪要。对 AI 而言，最有价值的输入不是抽象口号，而是结构化、可审查、可版本化的规范：例如上下文说明、边界条件、状态迁移规则、事件定义、验收标准和反例样本。只有当这些信息可以进入开发流水线，DDD 才真正成为 AI 的约束语言。

第三，在组织层面建立领域-工程-模型三方协作机制。DDD 的价值从来不只是架构师个人的思考方式，而是跨角色协商机制。在 AI 场景中，这种协作应扩展为领域专家、工程团队与模型使用者之间的持续校准；否则，AI 只会把团队内部的模糊性以更高速度放大。

十一、未来研究议程：从概念论证走向可验证命题

未来研究可以从三个方向推进。其一，建立基于真实项目的对照研究，比对"有无 DDD"或"弱 DDD / 强 DDD"在复杂业务场景中的缺陷发现率、返工率、需求一致性与跨团队沟通成本。其二，研究 DDD 产物如何以结构化文档、知识图谱或中间表示的形式进入 AI 开发流水线，从而验证"语义资产"是否真的能改善模型输出。其三，探索多智能体系统中的上下文治理机制，检验限界上下文是否能够作为 Agent 职责分解与冲突消解的有效原则。

十二、结语：复杂性理论视角下的 DDD 复兴

从理论上看，这些研究会把 DDD 从"经验性方法论"推进为"可测量的复杂性治理框架"。一旦这些命题得到充分验证，DDD 在 AI 时代的地位就不再只是工程师经验判断，而可以上升为具有解释力与预测力的研究对象。

因此，DDD 的未来不是退回过去，而是进入一个更高层次的位置：它既是组织知识的方式，也是约束生成式系统的方式；既是面向人类协作的语言，也是面向机器协作的语言。对 AI 编程时代的开发者而言，真正值得学习的不是"如何给模型多发几条提示"，而是"如何把复杂世界组织成模型可以守规矩地理解的世界"。

本文的最终判断可以概括为一句话：DDD 在 AI 编程时代并未过时，它只是被重新指认了真正的理由。这个理由不是微服务，也不是某种新兴工具，而是复杂性本身。只要业务世界仍然存在术语歧义、边界冲突、不变量与跨角色协商，DDD 就仍然是必要的。AI 越强，越需要让这些复杂性在模型之外被清楚地表达出来。

从这个意义上说，DDD 不是把开发者从编码劳动中解放出来的工具，而是把开发者从"模糊表达"的惯性中解放出来的方法。它迫使团队把"我们以为大家都懂"的东西改写成"任何人、任何模型都能检查的表达"。这也是本文将 DDD 视为 AI 编程时代的高价值建模语言，而非过时架构术语的根本原因。

十三、补充说明：为什么本文强调"语义治理"而非"技术替换"

本文多次使用"语义治理"这一表述，是为了强调 DDD 在 AI 时代的真正作用对象不是算法本身，而是人、组织与模型之间的意义协商。AI 能快速补齐技术实现，却无法自动解决组织内部对同一业务对象理解不一致的问题；而 DDD 的长期价值，恰恰在于让这些理解差异在系统设计早期就被看见、被讨论并被约束。

综上，本文并不主张把 DDD 绝对化为"所有 AI 项目的标准答案"，而是主张在复杂业务条件下，把 DDD 作为连接领域知识、规范文本与生成式实现之间的桥梁。只有在这一更严格的限定中，DDD 才能既避免被神化，也避免被误判为旧技术。

参考文献

1\] Evans, E. Domain-Driven Design: Tackling Complexity in the Heart of Software. Addison-Wesley, 2003/2004. \[2\] Evans, E. Guided Tour of Domain-Driven Design. Domain Language, PDF guide. https://www.domainlanguage.com/wp-content/uploads/2016/05/DDD-Nontechnical-path-through-the-blue-book.pdf \[3\] Fowler, M. Bounded Context. MartinFowler.com, 15 Jan 2014. https://martinfowler.com/bliki/BoundedContext.html \[4\] Fowler, M. Ubiquitous Language. MartinFowler.com, 31 Oct 2006. https://martinfowler.com/bliki/UbiquitousLanguage.html \[5\] Fowler, M. Domain Driven Design. MartinFowler.com, 22 Apr 2020. https://martinfowler.com/bliki/DomainDrivenDesign.html \[6\] OpenAI. Introducing the Model Spec. 8 May 2024; updated 12 Feb 2025. https://openai.com/index/introducing-the-model-spec/ \[7\] OpenAI. Inside our approach to the Model Spec. 25 Mar 2026. https://openai.com/index/our-approach-to-the-model-spec/ \[8\] GitHub. Spec Kit: Toolkit to help you get started with Spec-Driven Development. GitHub repository and documentation. https://github.com/github/spec-kit \[9\] Zhang, Q., et al. A Survey on Large Language Models for Software Engineering. arXiv:2312.15223, 2023/2024. \[10\] Fan, A., et al. Large Language Models for Software Engineering: Survey and Open Problems. arXiv:2310.03533, 2023. \[11\] Özkan, O., et al. Domain-Driven Design in Software Development: A Systematic Literature Review on Implementation, Challenges, and Effectiveness. arXiv:2310.01905, 2023. \[12\] Chen, Z., et al. Promptware Engineering: Software Engineering for LLM Prompt Development. arXiv:2503.02400, 2025/2026.