这是一个创建于 35 天前的主题，其中的信息可能已经有所发展或是发生改变。
最近在重构老项目，想问一下现在还有没有必要用 DDD 那套来重构呢？ go 语言加 DDD 配合 ai 变成会不会有意想不到的效果？
第 1 条附言 3 月 20 日
感觉好像确实没必要为了复杂而复杂，虽然 ai 可以生成很多东西
 | 1 imesrdfi8dzs 3 月 20 日 最近都是 AI AI AI,好久没听过 DDD 一词了. |
 | 2 gy0624ww 3 月 20 日 有 AI 应该利好 DDD ，TDD 这种 因为麻烦的测试用例不用你写了，DDD 分层也不用你写了 |
 | 3 Desdemor 3 月 20 日 这是一种架构方式啊，跟 ai 有啥关系，这俩可以重合。ai 做好 TDD 是真的方便 |
 | 4 weixind 3 月 20 日 我之前的看法是：“领域优先（ Domain-First ）+ 自包含（ Self-contained ）的组织方式大概率会取代传统分层架构。” 现阶段的 AI 生产力下，这个演进方向应该没啥问题，AI 再快速发展一两年，可能就不太适用了。 |
 | 5 sky3hao9 3 月 20 日 我现在认为 DDD 是一种编程思想, 跟有没有 AI 没多大关系, 会的仍然会使用, 我个人来说开发个新东西, 会先从实体和领域角度考虑, 按照业务扩展领域方法, 所依赖的都由接口约定. 最后去实现这些接口, 最后才会到建表,字段这些东西. 我觉得这种开发模式非常清爽 |
 | 6 liuzimin 3 月 20 日 我还以为是恶魔的破坏 |
 | 7 hrzlvn 3 月 20 日 ddd 反而是最好的方案吧，面向过程贫血的代码以后都会是个坑，可惜你要用 go ，否则有个 tocoai 原生支持 ddd ，不过他们只出了 java 版 |
 | 8 rocmax 3 月 20 日 via Android  1 怎么可能利好 ai 编程，ddd 一堆中间层得给 ai 搞迷糊了，运行时注入的框架都没法跳转到定义你让 ai 怎么理解代码。 |
 | 9 lujiaosama 3 月 20 日 我也在重构项目, 拷打了 AI N 遍之后, AI 让我用 分层架构 + 轻量 DDD. 复杂业务建模使用轻量 DDD. 纯 MVC 太容易整出一坨胖 SERVICE 了. |
 | 11 midsolo 3 月 20 日 正在用公司内部的 DDD 框架："菱形架构 + 南北网关 + case 编排 + 全局适配"，一个对象在不同的层级被转来转去，复杂的业务流程中要复制十几个，AI 都被绕晕了 |
 | 12 putaozhenhaochi 3 月 20 日 1 就没活过 |
 | 13 zhuanggu 3 月 20 日 现在是 SDD |
 | 14 Ketteiron 3 月 20 日 1 在 java 之外的语言强行上 DDD 只能说是没事找事嫌业务不够复杂。 |
 | 15 vincentWdp 3 月 20 日 我老了, 天然排斥没见过的模式, 所以我认为 ddd 就没活过 |
 | 16 Nzelites 3 月 20 日 ddd 这种罗里吧嗦的模式最适合 ai 去生了 不是说 ddd 不好 是虽然维护的时候好很多 但是写起来确实麻烦 心智负担重一些 |
 | 17 jackOff 3 月 20 日 现在老大要求禁止过度设计模式，意思就是代码不能写太抽象，必须新人能看懂，啥意思大家都明白 |
 | 18 lologame 3 月 20 日 3 DDD 本身就是伪科学，倒果为因，实现驱动设计，纯扯淡 |
 | 21 xing4576 OP @lujiaosama 现在的业务就是 mvc ，service 一大坨 |
 | 22 arthas2234 3 月 20 日 谁说 DDD 不适配 AI 的，我让 AI 帮我加个字段，好家伙从 client 层一直扫到 infrastructure 层，花了我不少 token ，AI 厂家笑嘻了。建议所有厂家都给自家 AI 训练成用 DDD 开发 |
 | 23 leegradyllljjjj 3 月 20 日 via iPhone DDD 本来就是为微服务设计的，微服务诞生以后 DDD 才发挥出真正的意义，之前一直都是一种建模工具，对实际的架构设计屁用没有 |
 | 24 beiyanpiki 3 月 20 日 AI 还是 DDD 好，MVC 一大坨 service 找上下文都困难 |
 | 25 luobingit 3 月 20 日 只知道现在有 AI 后 岗位 JD 上面基本没出现 DDD 了 都是 vibe coding |
 | 26 zhady009 3 月 20 日 1 KISS 模块内聚才是王道，DDD 纯给大家找麻烦 |
 | 27 darksword21 PRO 面条代码才是最好的！ |
 | 28 bololobo 3 月 20 日 https://soulhacker.me/posts/good-code/ 通过以上的分析，我们可以得到如下判断： 软件开发的基本范式还没有大的变化，软件工程中的核心问题（渐进式定义、复杂度控制、测试与验证）依然是我们面对的主要挑战。 本文前半部分的定义和定理体系仍然成立，只在一些具体细节上需要进行新的解读。 进入 Coding Agent 时代后，通过良好的代码架构来控制复杂度仍然非常重要，仍是最具效率的最佳实践；代码可读性和文档化的要求甚至高于过去；而对软件系统的测试与验证是亟待创新与突破的领域。 如此看来，在这个新的时代，好代码的标准并没有太大的变化；未来可能最大的变化是通过更可靠、高效的测试验证系统取代细致的代码评审，从而可以在软件系统总体复杂度受控的前提下忽略对代码细节的追求。 既然 "良好的代码架构来控制复杂度仍然非常重要", 那么达成这一目的的 DDD 自然也仍然非常重要. |
 | 29 thtznet 3 月 20 日 个人观点，AI 的最终形态将覆盖掉任何的设计模式。因为设计模式的产生本身就是为了人能更好的编写和测试代码，而 AI 对解决问题的代替作用，将逐步迁移到人类只需要关注 AI 解决问题的结果，中间过程，包括所谓的设计模式，都无关紧要，除非某些解决问题的过程中，仍然需要有人工协作，才可能保留一部分所谓的"设计模式"。 |
 | 30 kakki 3 月 20 日 真以为 AI 不需要抽象层啊?直接写二进制. |
 | 31 Gilfoyle26 3 月 20 日 有 Ai 了，还要什么 DDD ，直接 Ai 一把梭，早下班不好吗  |
 | 32 karmaisbitch 3 月 20 日 凉了 |
 | 33 momo2789 3 月 20 日 感觉从来没活过，领域有很多形式可以表达 |
 | 35 lmmlwen 3 月 20 日 DDD 和微服务已经被时代所淘汰 |
 | 36 doodle123 3 月 20 日 via iPhone DDD 是为人服务的，不是为机器服务的，以后 ai 主导编程，人类参与变少，自然也不需要 DDD 了 |
 | 37 irrigate2554 3 月 20 日 感觉 TDD 还挺适配 AI 的，DDD 就拉到吧，本来就没啥用的东西。 |
 | 38 rossroma 3 月 20 日 现在应该是 ADD ，AI Driven Design |
 | 39 lujiaxing 3 月 20 日 我个人认为是的. 什么 D 不 D 的, 在 AI 面前都属于废话. AI 生成代码就是突出一个糙猛快. 而且我们之所以用各种那个设计模式各种设计思想, 归根结底还是方便人类去维护. 但是现在都是 AI 去搞了, 屎不屎山的关我开发屁事? 屎山也是 AI 去爬不是我爬. 我管你那么多呢. AI 想怎么写就怎么写, 怎么快怎么来. 只要能实现功能, 把所有代码都写在一个文件里都 OK. |
 | 40 JoeSmith 3 月 20 日 |
 | 41 zhuhaohenry 3 月 20 日 DDD 对于 AI 有天然的优势啊, 层级清晰，足够单一职责，有上下文约束。AI 可以用极少的上下文就知道怎么去修改代码了，再加上 TDD, 就是绝配。 |
 | 42 SoviaPhilo 3 月 20 日 除非做好了每个迭代重新全量生成的准备，否则 DDD 应该还是现在 LLM context length 有限的情况下的一个比较可行的解决方案。至于什么时候更新一个版本就全量重做， 我估计还很远，因为这个 token 还蛮贵的，多的 token 多写一些稳定的业务不行吗 |
| 43 hrzlvn 3 月 20 日 看了楼上很多说 ai 找不到 ddd 字段的，你们去翻翻 tocoai 这个玩意，有点启发的，我也是醉了，这年头关键是找工具，倒不是说理论适不适合，你写一坨让 ai 去找，他又不是神仙。如果你说平血+过程也能跑的很好，而且你也是大系统，就当我没说哈哈，你的 ai 比较牛逼 |
| 45 hrzlvn 3 月 20 日 应该这样问，22 世纪了，有 ai 了，是不是 100 张表放在一个模块，同一个文件最好，因为上下文长度有 1G 了:) |
 | 46 MelodYi 3 月 20 日 VibeCoding 感觉上是利好 DDD 的。 但是说实话，“软件工程”相关的东西，感觉新时代都要大换血，会不会有别的不好说。 |
 | 47 unused 3 月 20 日 以后 AI 提需求出结果就行了，不需要 drive ，更不需要 design |
| 48 lujiaosama 3 月 20 日 我让 GPT 加入了讨论, 它说这里有 用过一点 DDD / 被坑过 + 把 DDD 当代码组织方式 + 理解“复杂性控制”本质这三类人.看起来还是孜孜不倦的推销 DDD. |
 | 49 lixintcwdsg 3 月 20 日 1 这本来就是不应该存在应被发明出来的东西，java 这一行做 toB 企业咨询的公司，为了给自己提高溢价，看起来“专业”，发明了很多方法学和概念。但是实际在互联网上做 ROI 落地变现，不能说是毫无作用，但是作用基本没用。 我是用了 java 快 20 年的人，为这句话负责。 只要你觉得听起来高大上，理解起来有点儿费劲儿，实际用起来别扭的东西，不好怀疑，都是这类。 restful 这些也类似，spring security 这种复杂设计也是如此，过去的 ejb 就不说了。 |
 | 50 acerphoenix 3 月 20 日 DDD 其实随着 java 被 go, c#, python, nodejs 等蚕食服务端市场时,就已经江河日下了. DDD 在 java 里还是不错的,尤其行业复杂业务场景. 但其实 go, python, nodejs 一把梭, supabase 等高效开发用效率弥补复杂设计, 拆的细点, 也很能打. |
 | 51 smileeast 3 月 20 日 其实还是控制复杂度，如果复杂度不高，那么怎么写都行，复杂度高，那什么框架和思想都不行，很多时候我们习惯加功能，但是功能越多越难维护，最后一点改动都会导致系统不可维护。 |
 | 53 gjinin 3 月 20 日 TDD 适合 AI |
 | 54 redbule 3 月 20 日 DDD 还是很适合微服务背景的 |
 | 55 skyyan 3 月 20 日 古法编程吗 |
 | 56 HappyAndSmile 3 月 21 日 AI 只合适粗暴平推代码 |
Select Language