用AI写代码时，领域驱动设计能帮你解决代码混乱问题

经常使用AI写代码的开发人员，可以了解一下领域驱动设计（DDD），它的英文全称为Domain-Driven Design。

不少开发人员平时写代码的习惯是先建数据库表，再编写增删改查逻辑，大量复杂业务判断分散在控制器和前端组件中。当需求逐渐增多后，字段和逻辑会相互缠绕，修改一处就可能引发多处故障。

DDD的核心思想，是将开发重心从底层数据库和框架转移到真实业务本身。在编写代码之前，先梳理清楚现实业务中的概念、规则和流转关系，让代码直接反映业务本身的逻辑。

传统软件工程中，落地DDD一般围绕三个核心动作展开。第一个动作是建立统一语言（Ubiquitous Language），在整个项目中给所有业务名词定下唯一标准，避免同一个概念在需求、代码、数据库中叫法不一，能直接减少沟通损耗。

第二个动作是划分限界上下文（Bounded Context），按照业务职责将系统切分成多个明确的独立边界，每个边界只负责自身的业务规则，跨边界调用只通过清晰的接口契约进行。比如电商项目中，商品展示、库存流转、支付结算各自为一个独立上下文。

第三个动作是构建充血的领域模型，不要编写只有字段、没有业务行为的空壳数据类，要将对应实体的业务校验、计算逻辑和状态流转直接封装在实体内部，让核心业务逻辑保持稳定。

掌握这套思路后，在大模型写代码的时代和AI协同开发会顺畅很多。大模型生成具体代码速度很快，但本质上是概率系统，如果只给它模糊需求，它大概率会生成一堆缺乏边界的混乱代码。

结合AI使用DDD，最佳分工是人类负责搭建领域模型与划定边界，AI负责高效补全具体实现，具体可分为四步操作。

第一步，建立全局的领域词汇表与契约文件，在项目根目录的规则文件或系统提示词中，用几分钟时间把核心实体名词、状态枚举和核心行为定义清楚。给大模型一套没有歧义的统一语言，它在命名变量、编写类型定义和生成接口时就不会出现前后矛盾的问题。

第二步，按照限界上下文限制AI的注意力范围，不要让大模型一次性处理几万行的大型项目，按照业务边界把代码组织成清晰的模块。每次给AI分配任务时，只提供当前上下文的实体定义、接口契约和相关文件，缩小上下文范围能大幅降低AI产生幻觉和误改代码的概率。

第三步，明确要求AI把业务规则内聚在实体内部，不要让AI在外层编写大量零散的条件判断，要求它把业务规则封装在对应的领域实体中。外层调用代码越简洁，后续修改逻辑或新增功能时，受影响的范围就越小。

第四步，用行为测试作为确定性契约，在让AI编写具体实现之前，先写好领域实体的行为测试用例，只有测试通过才算完成交付。用严格的单元测试和编译器，就能把大模型的概率输出稳定控制在正确范围内。

最终的分工模式为：人类理清业务概念、划定开发边界，AI负责快速落地编写代码。