为什么 AI 编程更偏向 DDD-style 架构

在我的开发经历中，我最讨厌的一件事就是去读别人的代码，尤其是当一个陌生项目甩过来的时候。如果代码里没有注释，那就更让人抓狂了。过去，如果项目使用了像 MVC 或微服务这样的标准架构，至少目录和分层清晰，理解起来还能顺利一些。但现实中往往不是这样，尤其是面对大规模或复杂项目时，一头雾水几乎是常态。

现在情况不一样了。AI 可以帮我们快速从整体到细节，逐步建立对项目的认知，让我们不必死磕每一行陌生代码。这就带来了一个新的问题：如何让 AI 更好地理解这个项目，同时把理解的结果呈现给我们，让我们也能快速上手？这正是现代 AI 编程架构需要解决的核心问题。

随着 AI 编程工具变得越来越聪明，团队开始发现传统的 MVC 或 LangChain-style 架构在大型 AI 项目中暴露出局限。业务语义不够清晰、模块边界模糊、AI 很难直接推理完整功能……于是越来越多团队转向 DDD-style + Clean Architecture，用业务领域而不是技术层来组织代码，让 AI 一眼就能明白系统在干什么，也让开发者自己看代码时更容易理解。

什么是 DDD-style

DDD，也就是 Domain-Driven Design，是 Eric Evans 提出的理念。核心思想很简单：软件的结构应该围绕业务领域，而不是技术层。

在 DDD-style 的项目里，目录通常是这样组织的：

domains/
  patient/
  medical_record/
  diagnosis/

application/
  use_cases/

infrastructure/
  database/
  llm/

对比传统 MVC：

维度	MVC	DDD-style
组织方式	技术层	业务领域
代码语义	隐含在逻辑中	直接体现在结构中
模块边界	模糊	清晰
AI 理解成本	高	低

也就是说，AI 在读代码时，一眼就能知道哪些是核心业务对象，不需要去推测每个 service 或 helper 的作用。

为什么 AI Coding 偏向 DDD-style

AI 在项目里执行任务时，主要做三件事：理解代码、理解业务、生成正确模块。DDD-style 在结构上天然支持这一流程。

语义清晰

业务模块用业务名字命名，例如：

patient
diagnosis
appointment
billing

AI 能直接理解业务，而不是盯着 “service” 或 “helper” 拼上下文。

边界明确

DDD 的 Bounded Context 把系统拆成独立领域，例如：

patient-domain
billing-domain
diagnosis-domain

AI 在修改 patient 相关逻辑时，只需关注 domains/patient，无需扫描整个仓库。

更适合 Agent 执行任务

AI Agent 常见任务：

Add new feature
Fix bug
Implement API
Generate tests

在 DDD-style 下，可以分解为：

Update domain model
Add use case
Expose API
Write tests

逻辑清晰，AI 推理效率高。

DDD-style 在 AI 项目中的结构示例

以一个 AI 医疗应用为例：

src/

domains/
  patient/
    Patient.ts
    PatientRepository.ts
    PatientService.ts

  report/
    Report.ts
    ReportGenerator.ts

application/
  createReportUseCase.ts
  analyzeMedicalImageUseCase.ts

infrastructure/
  openai/
  database/
  websocket/

interfaces/
  api/
  ui/

任务：Add feature: generate AI medical report

AI 可以推理出步骤：

创建 Report domain model
添加 ReportGenerator
写 createReportUseCase
在 API 层暴露 endpoint

整个过程清晰可控，模块边界明确。

现代 AI 框架的体现

OpenAI Assistants API：用 assistant、tools、threads、runs 抽象领域模型
Vercel AI SDK：用 ai、tools、actions 强调 use-case 导向
LangChain：早期结构 chains、agents、prompts、tools，容易出现 “prompt spaghetti”，团队逐渐转向自建 DDD-style 架构

DDD-style 在 AI 系统中的应用场景

AI SaaS：conversation、message、model、billing
AI 医疗系统：patient、medical_image、diagnosis、report
AI Agent 系统：task、agent、tool、execution、memory

新一代 AI 架构趋势

未来 AI 编程项目可能采用：

domains/
agents/
tools/
workflows/
llm/
interfaces/

AI 从单纯的代码生成器变成 autonomous developer，DDD-style 提供：

清晰业务语义
稳定模块边界
可推理的代码结构

未来思考：程序员如何与 AI 协作

也许就在某一天，可能就是 2026 年的某一天，当我们再去考虑架构的时候，程序员自己直接读懂代码的重要性，可能已经远远低于让 AI 更容易理解项目架构的重要性。那时我们需要考虑的，不只是“人类开发者怎么看”，而是如何让 AI 能够快速理解项目，同时在未来不同 AI 或新工具加入时，它们也能顺利接手、快速迭代开发。

反过来，这反而能让程序员腾出更多时间去思考更高层次的问题。在 AI 还不能完全像人类一样思考的时候，我们程序员需要用 AI 的思维方式来做架构和技术决策——考虑每个模块、每个技术选型时，都想着“AI 该怎么理解、怎么操作”。这样一来，AI 就能更好地辅助我们做决策、开发项目，让开发流程变得更高效、更可控。