探讨如何将领域驱动设计与 AI 智能体结合,解决大型遗留系统中 LLM 难以准确理解业务语义、命名混乱与边界模糊的难题,建立可增量演进、便于人机协作的软件工程新范式。
在过去的几年里,大语言模型已经深刻地改变了软件工程师的日常工作方式。从最初的好奇试用,到如今深度嵌入到编码、评审、重构、测试等各个环节,AI 的生产力红利被越来越多的人所感知。尤其是在绿地项目、小型工具或者全新模块的开发中,模型能够以惊人的速度生成可运行代码,让原本需要数小时甚至数天的工作压缩到几十分钟内完成。然而,真正在生产环境中负责多年演进的核心系统,情况却截然不同。那些经历多代工程师维护、依赖错综复杂、技术债积累深厚的代码库,往往让 LLM 的表现急剧下滑。模型会在本已混乱的概念之上再添新解,会在不需要适配器的地方强行引入抽象,也会在理应隔离的边界处径直穿透调用。
每一次这样的错误背后,都是一个本该由系统本身回答、却始终悬而未决的问题:当业务概念已经在代码中存在三种拼写时,哪一种才是真正权威的? 这种失败并非模型本身的能力缺陷,而是代码与组织尚未为协作做好准备的结果。一个运行多年的系统,其技术复杂度只是问题的第一层。在它之下,还潜伏着更深的一层困境:概念混乱、语义缺失、缺乏被团队共同认可并持续维护的统一语言。模型在面对这样一片语义的泥沼时,只能凭借概率去猜测,而猜测往往偏离真实意图。问题的根源不在于模型不够聪明,而在于系统本身缺乏可供模型依赖的结构性信息。可贵的是,这种准备并非一蹴而就的巨变,而是可以增量构建、逐步沉淀的工程过程。
一个值得关注的现实是,技术债的清偿从未像今天这般容易。技术债是软件工程的天然产物,业务决策的不断演进、开发节奏的持续压力、交付优先级的反复权衡,都让代码不可避免地积累瑕疵。传统的应对方式是划拨专项预算,通常是技术投入的一到两成,用于偿还历史欠账。理论上这合理,实践上却常常落空。关键在于,偿还技术债的成本由两半构成:决定应该改什么,以及把改动真正落到代码中。前者是设计判断,需要对系统结构、业务意图、变更影响有深入理解;后者是机械执行,是类型声明、结构调整、测试补充这类体力活。
在过去,这两半的成本大致相当,决定和实施各占一半时间。而现在,实施这一半的成本被 LLM 彻底压扁。一个精心设计的清理方案,无论是抽取模块、跨包重构,还是补齐测试覆盖,都可以由模型以远低于过去的代价完成。决定该做什么,仍然是工程师不可替代的工作;但真正敲下键盘的那一半,已经变得前所未有的便宜。 理解这一变化,关键在于区分两类不同性质的工作。可以借用约翰·奥斯特豪特在《软件设计哲学》中提出的概念,虽然这里对它的用法有所引申。
他用战术与战略来描述编码时的两种态度:战术式编程关注立即让功能跑起来,战略式编程则关注在过程中持续投入设计。这里借用同样的词汇,但划分的是作者的角色。战略性工作是决定:阅读系统、推演变更、评估影响、确认改动的真实价值。战术性工作是把已经做出的决定落到具体的代码文件中。前者要求对系统有整体的、深入的理解,后者则是已经被 LLM 大幅提速的部分。 在实际工作中,战略性部分需要工程师全程投入,战术性部分则更多扮演评审者的角色。
在战略性路径上,深入分析代码库,评估需要实施的改动,判断它与目标功能的对齐程度,最终产出的成果是写入仓库的 GitHub Issue。这些 Issue 描述清晰、范围明确、附带验收标准,是与 AI 系统协作的起点。 Issue 接下来会被一个由技能与子智能体构成的 AI 系统接手执行。技能是一份书面化的操作流程,通常以 Markdown 文件形式存在,描述模型在特定任务下应当遵循的步骤。当任务与技能描述匹配时,模型加载该文件并按照其中的指引行动,例如"处理一个 Issue"或"重新生成上下文映射"。这让同一类任务每次都以同样的方式被处理,而不是依赖于当天的心情或临时的措辞。
子智能体则是独立的模型会话,拥有全新的上下文窗口,承担单一的明确职责,例如实施代码、进行安全审查、核对规约符合度,并向主会话回报结果而非倾倒整段推理过程。 当改动完成后,PR 已经准备就绪。工程师进入评审环节,逐项确认改动是否合理、是否需要进一步调整。这种评审可以增量进行,重点关注测试覆盖与影响面:在改动落地之前,必须清楚系统中还有哪些部分在消费正在被修改的对象,这些下游是否能够承受即将发生的变化。此时的工程师更像是一个协调者与规划者,为系统的演进绘制路径,而不再亲自敲下每一行实现代码。时间被真正节省下来,被投入到那些只有人能胜任的判断之中。
那么,战略性工作究竟有多大的价值?它的价值完全取决于它所使用的表达语言。这正是领域驱动设计登场的原因。 领域驱动设计,由埃里克·埃文斯系统阐述,长期以来都是构建可演进软件的重要选择。它通过通用语言与限界上下文,把业务需求直接翻译为技术实现,让业务方与技术方在同一个语义空间内对话。当智能体加入这个回路时,这种连接变得更加关键:它既是工程师向模型陈述需求的方式,也是模型向工程师解释其推理的媒介。模型的输出需要被读懂、被打回、被追问,而这些都要求双方共享一套可被精确引用的语言。
要让这一切可执行,需要一种被代码库自身携带的、可被工具读取的领域声明。每个工程师维护的仓库根目录下,放置一个 .workflow.json 文件。这是仓库的清单,告知工具这个仓库是什么:由哪些语言组成、哪些目录应当被智能体优先阅读、哪些校验必须通过才能让改动被接受。该文件中有一个区块专门用于声明领域信息,这也是仓库唯一需要注册的入口。不存在第二个可能与代码脱节的注册表。 领域区块中,项目名称、限界上下文列表、每个上下文的术语表位置、子领域类型、与相邻上下文的每一条边界,都被明确列出。
以一个真实项目为例,这是一个求职申请追踪工具,由两个仓库组成:一个 Rust 后端服务,与一个 Web 前端。后端的清单描述自己为某类语境的提供方,前端的清单则声明自己为该语境的使用方。读取边界描述的顺序应当是自然的:先看对端的地址,确认是哪两个上下文相连;再看方向,判断调用关系的走向;接着是归属,决定当两端出现分歧时谁的概念具有权威性;然后是关系模式,取自一个封闭的词汇表;最后是一段自然语言说明,解释为何简单的标签无法完整描述这里实际发生的情况。在前端这一侧,对后端的读取路径同时承担了两种角色:写入时直接采用后端的形态,读取时则通过防腐层翻译为自己的形态,因此单一标签只能准确描述其中一半,必须用一段说明补全另一半。 在清单文件旁边,是每个上下文对应的 CONTEXT.md 文件。这是该上下文的活术语表,记载每一个术语在此处的精确含义,以及被刻意拒斥的同义说法。
两个文件共同构成上下文的领域基线,由持有代码的仓库自身维护。没有任何比它们更高层的产物需要被人工撰写:所谓的上下文映射,即那份展示全部上下文与全部边界关系的全局文档,是被自动生成的。一个脚本遍历磁盘上的所有仓库,合并其中的领域区块,最终输出一份统一的 CONTEXT-MAP.md。这份映射是可丢弃的、可重新生成的,它始终只是底层声明的衍生物。 回到这个求职项目。后端仓库持有产品语言,持久化职位、档案、档案变体、简历、求职信这些概念,并遵循一条简单规则:当两个上下文同时需要表达同一个术语时,持有持久化状态的那一侧拥有这个词的定义权。
前端仓库则只持有界面词汇,例如视图模型、筛选状态、分面统计,并将其余所有术语标记为已发布状态,原样取自后端基于 OpenAPI 自动生成的 TypeScript 类型。这正是智能体工作所需要的精度水平:把前端仓库指给模型,它立刻知道在此处重命名职位概念是越权行为,知道读路径上的适配器是有意为之,也知道哪些词汇是允许自由创造的。借助全局映射,模型清楚自己身处哪个上下文;借助本地术语表,模型清楚这个上下文使用的具体词汇。 这条规则的力量在于对称性。每一条边界都由两端各自声明,这种重复本身就是设计的关键所在。生成器对两端声明进行交叉核对,核对的规则需要细致:提供方陈述自己的立场,例如发布式语言;消费方陈述自己的立场,例如跟随者、防腐层;核对工作实质上是一张配对表,验证两端声明是否彼此一致。
这个核对被封装为一个技能,在三个关键时机触发:刚刚修改过清单时、正在接入一个新仓库时、即将改动另一上下文所依赖的内容之前。每一处报告的不一致都是一个发现:一条边界、一种两端声明对不上的具体方式。借助一个简单的标记,这个技能会把每条发现作为一个领域驱动设计相关的 Issue 写入持有错误声明的那一侧仓库。Issue 带有一个指纹,由发现类型与两端地址共同构成,这样在部分修复后再次运行时,会更新同一 Issue 而非另开一条;当某条发现不再出现时,对应的 Issue 也会被自动关闭。从此之后,这条流程与系统中的其他所有工作遵循同一条主干:一条 Issue、一个智能体、一份 PR、一次人工评审。 至此,战略性层面的基础设施已经就位。
它解决了上下文的边界在哪里、上下文之间如何对话这些根本性的结构问题。然而,任何单一上下文的内部,仍然是普通的代码,仍然允许构造出语义上毫无意义的领域对象并将其成功保存。 随着全局映射与术语表的落地,下一步可以聚焦到代码本身:一次处理一个上下文,将其迁移到由领域驱动设计原语构成的真实领域模型,价值对象、聚合、领域服务、规约等抽象逐一登场。这个迁移过程,正是让代码库有能力回答模型曾经只能靠概率猜测的那些问题:这个词到底是什么意思,谁拥有它的定义权,这个上下文在哪里终止。所有这些答案,将以代码、术语表与全局映射三者一致的形式被沉淀下来。届时,再把同一个仓库交给同一个模型,它的输出将变得截然不同:不再有第四种拼写,不再有跨越边界的不当调用,不再有凭空发明的接口。
这套方法并非某个人的特殊偏好,而是一种可以逐步落地的工程纪律。它的每一步都对应着清晰的产出物,每一个产出物都可以被版本控制、被评审、被回滚。技能可以被复用,子智能体的职责可以被拆分,Issue 可以被追踪,PR 可以被审查。它把过去那种只能凭借个人记忆与默契的隐性知识,转变为代码仓库中显式声明、可被工具读取的结构性信息。LLM 的能力边界由此被显著扩展:它不再是面对一片混沌语义随意发挥的工具,而是被引导在一个被精心维护的认知空间内行动的协作者。 对于正在与遗留系统搏斗的团队而言,这条路径值得认真考虑。
它不需要一次性推翻现有架构,不需要暂停所有业务交付,也不需要等待某个完美的迁移窗口。它所要求的,是承认代码与组织尚未为高强度的 AI 协作做好准备,并愿意为此投入一小部分精力,构建那些让模型能够正确理解系统的支撑结构。当这些结构逐步就位时,偿还技术债的工作将不再是一个令人生畏的项目,而是一项可以按 Issue、按上下文、按 PR 持续推进的常规工程实践。决定该做什么,仍然是工程师的职责;把这部分决定告诉一个懂得边界的智能体,让它去完成剩下的部分,将成为下一代软件工程师的标准动作。 。
