DDD 没有消亡，消亡的是“教条式”的 DDD。

领域驱动设计 (DDD) 没有消亡。

由于 AI 的出现，DDD 的核心价值反而变得更加重要。你仍然需要：

  • 理解复杂的业务领域
  • 定义限界上下文 (Bounded Contexts)
  • 统一工程师与专家之间的语言
  • 发现不变性 (Invariants)
  • 使状态转换显式化

AI 让代码生成的成本变得极低。这使得思维不清晰变得更加危险。如果你的领域逻辑本身就很混乱，AI 只会帮你更快地制造混乱。

问题不在于 DDD，而在于“教条式”的 DDD (Cargo-cult DDD)。

许多团队将战术性 DDD (Tactical DDD) 作为一种控制手段，而非理解手段。他们只是为了遵循模式而遵循模式：

  • 创建一个实体 (Entity)
  • 添加一个仓储 (Repository)
  • 编写一个映射器 (Mapper)
  • 遵循目录结构

这些模式本身并不坏，但它们往往变成了“架构文书工作”。如果一个 Repository 只是改了名字的 DAO，或者一个 Mapper 只是毫无意义地搬运字段，那么你并不是在进行领域建模，而是在填表。

这就是披着架构外衣的官僚主义。

AI 非常适合这类工作。它可以在几秒钟内生成 Mapper、DTO 和样板代码 (Boilerplate)。

如果你利用 AI 来加速官僚流程，你只是在加速“仪式感”。你可能会看到更多的任务单在推进，但你并没有构建出更好的系统，你只是降低了制造浪费的成本。

真正的竞争在于两类组织之间：

  1. 大型 AI 辅助的官僚化团队 这些团队利用 AI 生成更多的层级和更多的样板代码。他们专注于遵循现有模式并通过形式审查。

  2. 小型 AI 赋能的高自主权团队 这些团队利用 AI 来提升安全变更系统的能力。他们专注于：

  • 可执行规范 (Executable specifications)
  • 强边界
  • 自动化测试
  • 类型级约束 (Type-level constraints)
  • 显式状态转换

第一类团队利用 AI 制造更多的“仪式感”；第二类团队利用 AI 来消除对“仪式感”的需求。

不要再利用架构来控制人员或代码，而要利用它来保护领域的含义。

从“依靠人工审查保护的架构”转向“依靠测试、类型和约束保护的架构”。

Source: https://dev.to/terum/ddd-is-not-dying-cargo-cult-ddd-is-l1p

Optional learning community: https://t.me/GyaanSetuAi