陈大黄 (@realchendahuang) “经常用 AI 写代码的朋友们，可以了解一下领域驱动设计（DDD）这个概念。它的英文全称” — TopicDigg

经常用 AI 写代码的朋友们，可以了解一下领域驱动设计（DDD）这个概念。它的英文全称是 Domain-Driven Design。 平时做开发，很多人习惯先建数据库表、写增删改查，然后把一堆复杂的业务判断散落在控制器和前端组件里。一旦需求变多，字段和逻辑到处缠绕，改一个地方就坏一片。 DDD 的核心思想，就是把重心从底层的数据库和框架，拉回到真实的业务本身。在动手敲代码之前，先理清楚现实业务里的概念、规则和流转关系，让代码直接反映业务本身的逻辑。 在传统软件工程里，落地 DDD 通常围绕三个核心动作展开。 第一个是建立统一语言（Ubiquitous Language）。 在整个项目里，把所有的业务名词定下唯一标准。同一个业务概念，不能在需求里叫客户，在代码里叫用户，在数据库里又叫账号。统一了词汇表，沟通损耗直接抹平。 第二个是划分限界上下文（Bounded Context）。 再大的项目，也不能揉成一团。按照业务职责把系统切分成几个明确的独立边界。比如电商项目里，商品展示、库存流转、支付结算各自是一个独立的上下文，每个上下文只管好自己的规则，跨边界调用只通过清晰的接口契约进行。 第三个是构建充血的领域模型。 不要写那种只有字段、没有业务行为的空壳数据类。把属于某个实体的业务校验、计算逻辑和状态流转，直接封装在实体内部，让核心业务逻辑保持稳定。 搞懂了这套心智，在 Vibe Coding 时代跟 AI 协同就会顺手得多。 大模型写具体代码的速度极快，但它本质上是个概率系统。你给它一段模糊的需求，它顺着概率去猜，必然会胡乱生成一堆缺乏边界的胶水代码。 结合 AI 使用 DDD，最舒服的姿势是做好分工：人类负责搭建领域模型与划定边界，模型负责高效地补全具体实现。 具体的最佳实践可以总结为以下四步： 第一步，建立全局的领域词汇表与契约文件。 在项目根目录的规则文件或者系统提示词里，花几分钟把核心实体名词、状态枚举和核心行为定义清楚。给大模型一套毫无歧义的统一语言，它在命名变量、写类型定义和生成接口时就不会前后打架。 第二步，按照限界上下文限制 AI 的注意力范围。 不要试图让大模型一次性通读并理解几万行的大工程。按照业务边界把代码组织成清晰的模块。每次派发任务时，只把当前上下文里的实体定义、接口契约和相关文件喂给模型。把上下文体积控制在极小范围，模型的幻觉和误改率会大幅下降。 第三步，明确要求模型把规则内聚在实体内部。 给 Agent 提要求时，限制它不要在外层写一堆零散的条件判断补丁，而是把业务规则封装在对应的领域实体里。外层的调用代码越干净，后续让模型修改逻辑或者新增特性时，波及的范围就越小。 第四步，用行为测试作为确定性契约。 在让 AI 敲具体实现之前，先把领域实体的行为测试用例立起来。跑测试通过了才算交付。用严格确定性的单测和编译器，把大模型的概率漂移稳稳按在轨道里。 人类理清概念与划定边界，AI 负责快速落地代码。