2026 开篇：架构师为什么不用 DDD ？沉默是金，总会发光大家好，我是沉默这不是一篇 DDD 教程，也不是最佳实

沉默是金，总会发光

大家好，我是沉默

这不是一篇 DDD 教程，也不是最佳实践指南。

这是我在真实项目中尝试使用 DDD 之后的困惑、挣扎，甚至是放弃。

如果你正在考虑要不要上 DDD，

或者你已经在用，但总觉得哪里不对劲，

那这篇文章，可能会戳中你。

**-**01-

DDD 第一个让我崩溃的点

**
**

CQRS 分类，现实世界根本不配合

DDD + CQRS 的世界里，所有操作都应该被清晰地分成三类：

Command：只负责“改状态”，不关心返回值
Query：只读、幂等、轻量
Event：对“已经发生的事情”的被动响应

听起来很优雅，对吧？

但现实是：大量操作，三个都不是。

一个真实到不能再真实的例子

我们做了一个「服务调用系统」，用户通过 API 调用第三方服务：

POST /api/service-invoke-requests

{
"serviceId":"weather-api",
"inputData":{
    "city":"Beijing"
    }
}

同步返回结果：

{
"requestId":"req-123",
"status":"SUCCESS",
"outputData":{
    "temperature":"25°C",
    "weather":"Sunny"
    }
}

现在问题来了——
这到底是 Command？Query？还是 Event？

**
**

它是 Command 吗？

Command 理论上应该只返回 id / status
但这里要返回完整的业务结果
而且它本质上是“读取用户配置 + 调用外部服务”

不符合。

那是 Query 吗？

Query 应该是只读、轻量、幂等
但这个接口可能扣费、发短信
可能执行几秒甚至更久

还是不符合。

Event？

Event 是“事情发生之后”的通知
这是用户主动发起的请求

也不是。

结果：三个都不是

你会发现，现实系统里有大量这样的操作：

操作	改状态	返回数据	同步	CQRS 分类
用户注册	✅	❌	✅	Command
查询用户列表	❌	✅	✅	Query
调用第三方服务	✅	✅	✅	❓
生成报表	❌	✅	❌	❓
AI 生成内容	✅	✅	✅	❓

灰色地带，才是主流。

我的真实感受

很多操作 既改状态，又要返回复杂数据
不同人对 CQRS 定义理解完全不同
Code Review 经常变成：

“这个到底算 Command 还是 Query？”

最后发现：
争论半天，对业务毫无价值。

所以我后来干脆：

// 与其纠结
CreateUserCommand
QueryUserByIdQuery

// 不如实用
CreateUserRequest
GetUserByIdRequest

不“纯粹”，但省时间、不内耗、能交付。

- 02-

第二个让我放弃 DDD 的点

聚合根边界，真的太难判断

DDD 说：

聚合根是事务一致性的边界。

听起来很清晰，直到你真的开始建模。

一个让我纠结了很久的例子：收藏功能

用户收藏文章，看起来简单得不能再简单。

但你一旦开始用 DDD 思考，马上陷入泥潭：

收藏属于 User？
还是属于 Article？
还是一个独立的聚合根？

从不同视角看，结论完全相反

从用户角度：

收藏是“我的收藏”
用户删了，收藏要不要删？不一定

像 User 的一部分，又不完全是。

从文章角度：

收藏影响文章的收藏数
文章删了，收藏要不要删？也不一定

像 Article 的一部分，又不完全是。

从行为角度：

有 ID
有创建时间
可单独查询

看起来像独立实体。

但换个现实角度：

它不就是一张多对多中间表吗？

用 DDD 理论去“严格推导”，只会更混乱

一致性边界？
→ 收藏根本不需要强一致
事务边界？
→ 收藏数完全可以异步更新
生命周期？
→ 依附谁都不完全合理

最后你会发现：

是否是聚合根，取决于你打算以后怎么玩这个功能。

而不是 DDD 给你的某个“明确规则”。

我的结论

同一个功能
不同阶段
不同团队

建模方式完全不同。

而 DDD 给你的，是一堆“看起来有道理，但无法落地的判断标准”。

- 03-

最致命的一点

DDD 和性能优化，是天然对立的

这是我真正放弃 DDD 的原因。

真实问题：User 表太大，必须拆表

1000 万用户
80% 查询只要 username / email
表里却有一堆 TEXT / JSON 大字段

拆表后，性能立竿见影。

但 DDD 告诉你什么？

User 是聚合根，Repository 应该返回 完整 User

于是你陷入死循环：

返回完整聚合 → 性能差
按需加载 → 破坏聚合完整性
懒加载 → N+1 查询地狱
多粒度查询 → User 对象时完整、时残缺

你写的每一行代码，都在 DDD 理论和性能现实之间妥协。

本质矛盾

DDD 假设：加载完整聚合不是问题
现实世界：性能才是第一约束

这个矛盾，无解。

**-****04-**最后一个现实问题

DDD 太花时间了

建模时间是 CRUD 的 2～3 倍
需求却随时可能被砍、被改、被推翻
团队对 DDD 理解不一致，沟通成本极高

很多时候你会发现：

还没来得及体现 DDD 的价值，需求已经变了。

**-****05-**总结

最后想说的几句大实话

1. 大多数项目，根本不需要完整 DDD

80% 的系统就是 CRUD
强行 DDD，只会增加复杂度

2. DDD 的思想是对的，但方法已经老了

关注业务语言
领域拆分思路
教条式建模

3. 现实中的 DDD，都是“DDD 风格”

Command 返回业务数据
查询直接写 SQL
为性能破坏聚合完整性

我们用的是 DDD 的外壳，而不是 DDD 本身。

DDD 不是银弹。真正的问题，是错把它当成教条，而不是工具。

没有完美的架构，只有合适的架构。

**-****06-**粉丝福利

我这里创建一个程序员成长&副业交流群， 


 和一群志同道合的小伙伴，一起聚焦自身发展， 

可以聊：


技术成长与职业规划，分享路线图、面试经验和效率工具， 




探讨多种副业变现路径，从写作课程到私活接单， 




主题活动、打卡挑战和项目组队，让志同道合的伙伴互帮互助、共同进步。 




如果你对这个特别的群，感兴趣的， 
可以加一下， 微信通过后会拉你入群， 
 但是任何人在群里打任何广告，都会被我T掉。

2026 开篇：架构师为什么不用 DDD ？