1. Vibe Coding 带来的效率提升和问题
从Vibe Coding火了之后，我就一直在不断的在使用AI写一些自己感兴趣的小项目，有试过人机共写，但更多的还是只下命令，代码怎么写，技术栈用什么全由AI自己决定。这两年用AI写了大大小小一二十个项目，但是体验下来最大的感受就是刚开始AI的开发速度确实很快，但是随着想要的功能越来越多和业务规则越来越复杂，AI的上下文窗口似乎总是不够用，不管是claude还是gpt codex系列，在系统体量大了之后让AI再进行功能改动的时候AI总是顾此失彼，往往一个功能要改动两三次，并且代码审查下来非常痛苦，能够感觉开发效率明显的降低。
正巧前几天看到一篇很有意思的文章：《什么是AI友好型架构》。里面核心观点就是喂给AI丰富的领域上下文，并且这个领域上下文也易于被人类工程师理解，方便人机合作。
在看到这篇文章之后，我脑子中第一个想法就是：这不就是DDD的思想吗? 正巧我也算是在DDD领域小有经验，我就结合自身的开发经历和大家做一些小小的探讨，欢迎大家一起讨论。
2.让AI做自己擅长的事情
AI擅长的是“写代码”，而非“理解业务”。它可以根据指令生成CRUD操作，却难以洞悉“VIP用户+活动商品+积分过期+上限规则”这类复杂业务规则的组合逻辑与内在约束，在面临这类场景时AI往往会进行简单粗暴的if-else堆积，不仅代码丑陋可维护性也是一坨。因此，一个关键问题浮现：在AI辅助开发成为主流的当下，我们是否需要一种新的架构范式来“驾驭”AI，使其生成的代码不仅“能跑”，更能“活得长久”？
我想领域驱动设计（DDD） 能够回答这个问题。DDD并非过时的教条，而是构建AI友好型架构的基石。这种架构的核心在于，通过清晰的业务边界、稳定的领域模型和明确的职责分层，为AI的代码生成提供精确的“地图”和“约束”，从而将AI的生产力从生成“代码堆”导向构建“业务系统”。
3. DDD的精炼过程：为AI提供清晰的业务上下文
DDD的核心实践之一，是通过战略设计识别并界定限界上下文（Bounded Context） 。这个过程本身就是对庞杂业务知识进行梳理和精炼的过程，其结果是为系统划分出语义明确、内聚性高的业务模块。这与context engineer中的上下文精简的思想不谋而合。例如，在一个智能推荐系统中，可以清晰地划分出“用户画像上下文”、“推荐算法上下文”和“内容管理上下文”。这种精炼不仅可以保证AI的上下文窗口能够尽可能的减少干扰信息，还能让AI和人类工程师对于业务规则的理解处于一致水平。
首先，统一语言（Ubiquitous Language） 确保了业务概念在特定上下文中的含义唯一且稳定。当开发团队与AI协同工作时，使用“订单”、“客户”等业务术语，而非“T001W”、“KNA1”等技术表名或字段缩写，能极大降低AI的认知负担，使其生成的代码直接反映业务意图，减少因术语歧义导致的“幻觉”或错误。其次，明确的上下文边界如同给AI划定了“思考范围”。当AI需要处理“预约挂号”功能时，如果它明确知道该功能属于“预约调度上下文”，它就能更专注地调用该上下文内的领域服务（如AppointmentSchedulingService）和聚合根（如Appointment），而不是将用户认证、支付计费等无关逻辑耦合进来。换言之，DDD把领域知识精简为一个个高内聚的上下文的过程，就是为AI预先完成了业务逻辑的“分门别类”，使其能够更准确、更聚焦地理解和实现业务规则，也能够帮助AI写出来更加优雅的代码，经过我的实践经验，领域上下文划分的越清晰，AI写出的代码质量就越高，甚至可以实现代码即文档，大大降低维护成本。
4. DDD的解耦价值：防止AI生成耦合的“大泥球”
缺乏架构指引的AI代码生成，极易催生被称为“大泥球（Big Ball of Mud）”的高度耦合系统。一个典型的反面案例是，AI可能生成一个巨型的BusinessService类，其中混杂了参数校验、业务计算、数据库查询、消息发送等所有逻辑，形成“if else if else”的迷宫。这正是Vibe Coding的潜在代价：代码能快速运行，但丧失了可维护性和可演进性。
DDD通过战术设计模式，如聚合（Aggregate） 、领域服务（Domain Service） 和应用服务（Application Service） ，有效地对抗这种耦合趋势。DDD的核心思想是“让业务对象自己对自己的行为负责”，而非将规则写在无所不能的Service里。例如，在预约系统中，关于“时段冲突校验”的规则应封装在Appointment聚合根内部或专门的SchedulingService领域服务中，而不是散落在应用层的各个角落。当AI在DDD架构下生成代码时，这种职责分离的模式会引导它：将状态变更逻辑放在实体方法中，将跨聚合协调逻辑放在领域服务中，将用例编排逻辑放在应用服务中。这样，AI为了实现某个业务规则（如“取消订单并退款”），就不会把订单状态更新、库存释放、支付逆向等多个领域的知识硬编码在同一个方法里，而是通过调用不同上下文的领域服务来协作完成。这种基于业务语义的抽象和解耦，是防止AI制造“屎山群”的关键拦截器。
5. DDD的接口与分层：让AI专注技术实现，隔离变更风险
DDD经典的分层架构（用户界面层、应用层、领域层、基础设施层）与清晰的接口设计，为技术细节的替换和演进提供了安全边界。这对于AI辅助开发尤其有价值，因为它允许我们将“业务规则”与“技术实现”的关注点分离。
领域层封装了最核心、最稳定的业务规则和不变式，它不依赖于任何具体的技术框架（如JPA、MyBatis、Redis）。应用层负责协调领域对象完成具体的业务用例，它同样保持技术中立。而具体的数据持久化、外部API调用等技术细节，被隔离在基础设施层，并通过接口（如Repository）向领域层提供抽象。这种设计带来了两大优势：第一，当需要替换底层技术时（例如从JPA切换到MyBatis，或引入新的向量数据库用于AI特征检索），风险变得可控。AI只需要关注基础设施层中具体实现类的重写，而完全不需要触碰领域层和应用层的业务逻辑代码。因为业务规则被妥善地保护在领域模型中，技术实现的变更不会波及业务核心。第二，这提升了AI生成代码的针对性。我们可以指示AI：“在example.domain包下，生成Product聚合根的领域模型”，或者“在example.infrastructure.persistence包下，实现基于MyBatis的ProductRepository”。AI可以分别运用其对业务建模和特定ORM框架的知识，写出更高质量、职责更单一的代码，而无需在同一个任务中混淆两种截然不同的知识。在这里给大家分享一个小技巧，在使用特定技术栈的的实现的时候，如果自己对这个技术没有充足的信心，可以去找一下对应的skill，结合skill能够帮助AI写出来更高质量的代码。
6. 展望
综上所述，DDD并非与AI时代背道而驰，而是确保AI生成代码具备高质量、可维护性和业务适应性的关键架构纪律。良好的DDD设计通过统一语言、限界上下文、聚合与分层，构建了一个对AI友好的“语义清晰、结构稳定”的编码环境。
因此，在AI重塑软件工程的今天，DDD的价值不仅没有削弱，反而更加凸显。它从“优雅架构”的追求，升华为“智能开发”的必需品。AI让我们写代码的速度提升了十倍，而DDD则确保我们生成的系统能够稳健运行十年。真正的AI原生工程师，不仅仅只是会利用AI的生成能力来提升开发效率，更是深刻掌握DDD等架构思想，能够将业务复杂性有效“编码”到系统结构中的组织者与设计者。“工具终会普及，判断力才是关键”。未来，结合DDD的语义建模与基座大模型能力，终会实现从领域模型到数据平台的全链路AI驱动开发，彻底打通业务与数据之间的鸿沟。这或许正是软件工程3.0时代，高质量系统开发的破局之道。
