给 AI 编程划条边界：DDD 复估

领域驱动设计这套老办法，被 AI 编程翻出来重估了一轮。

评论区的一线反馈比正经文章还密，梳理下来两头都硬。先说赞成的。给机器立的规矩一条省不掉，过去为人际沟通准备的繁文缛节倒可以扔。天天让代理写生产代码，代码还没出乱子，名字先乱了。同一个概念在几轮对话里冒出三个叫法，回过神，文档一处、代码一处、台账又一处。

第二条是上下文的密度，把聚合根和值对象直接递给模型，胜过丢一堆增删改查让它自己悟。有人补了教训，增删改查补得极快，没有边界图的话，缠得也极快。规则散落是常事，同一句话被抄到四五处，改了这头忘了那头。

反对的也有话说。有人提醒，这套只值复杂的企业系统上，小项目走传统 MVC 就够，别为概念而概念。还有人翻出前司旧账，某团队把 DDD 讲得故弄玄虚，为的是护住架构师的位子，本想减少沟通损耗的工具，反倒把损耗放大了好几倍。

落地那栏最实在。指望插件管住模型，靠不太住。现阶段更划算的做法是，规则文件搁在项目根目录，实体、状态、边界逐条写死。动手前先把行为测试立起来，让确定性的单测把模型的概率输出按在原地。

"立规矩那部分省不掉"这半句是全场重心。前面模型不动砍三倍开销讲的是往提示里做减法，这条讲的是往规则里做加法。跟前面一周只开两三次呼应，那条是工具在变少，这条是底线在变清，两头都在回答同一件事，交给它干之前自己得先想明白。

老方法翻新这个循环我留意，DDD 十几年前为沟通而生，如今沟通对象换成了模型，概念一个没多，用途却换了一整套。

我留的疑问有三处。名字乱掉的修复成本没人算；行为测试先立的覆盖率没给；复杂度多高才值得上这套，界线也没划。

这周拿最近一个项目的规则文件对着四步过一遍，先看名词那一条守没守住。