请问 2025 还有 DDD 成功有名的公司案例吗?

只能说改东西巨麻烦，中小厂还是最好别碰

组织架构适合 DDD 么，不适合别搞

特别屎，要是再叠加没有分离团队的“微服务”就更屎了

统一语言这个提法和实践还是挺好的，跟业务之间能够减少分歧和误解，方便建立正确的业务模型。至于其他的缺乏工程实践的标准，很难推广。

上一任技术负责人推了两年 ddd ，最后拿了大礼包跑路了

DDD 只在写 demo 的时候很成功

我倒是觉得 DDD 是软件工程里一个在敏捷开发的基础上搞出来的一个好理论，很适合研发占比高的初创团队。

说白了就是混淆业务和程序的界线，产品经理也是开发者，开发者也是测试人员，大家拥有同一套业务知识，团队的组织架构、微服务的模块划分和领域对象的限界达成一种统一。

很多技术负责人主推的 DDD 有点戴着镣铐跳舞，产品、测试人员可能还停留在瀑布式开发的工作方式，技术主推的 DDD 就会变成一种编码层面的内耗，在这种团队里，开发人员作为需求的下游，往往既要协调上游产品的思路，依靠不完整的领域知识去硬套，又要处理下游测试人员的反馈，属实是夹板气。

但是部分思路或者设计模式，比如领域建模、事件驱动，还是值得学习，并应用在具体的工程实践中的。

严格说 DDD 在不合适的编码场景，不合适硬用结果不好用，是现在很多 DDD 方案让人难受的根源。
DDD 本质上不是一个开发范式，是一个思路，是一个解耦思路。
不理解思路硬要在软件工程上用不合适的东西实现，那是学院派没事找事。
开个地图炮：JAVA 开发者最爱干这事。

区块链的链本身就是 DDD 范式的最好体现，这一点所有区块链都是 DDD 的成功案例。
链本身只关注交易，只关注行为，并不关注结果，结果是基于全链计算得到的。
这就是 DDD

让事情的变化通过事件记录进行解耦的抽象过程。
按这个往外推，其实很多时候就已经用到 DDD 的思路了。

感觉最好就是在产品设计和拆分微服务的时候指导用用，拆分后的微服务开发就按照正常来比较合适

我觉得很搞笑的是，有些人写了一些看似是分层的代码就自认为是采用了 DDD ，但是当你问他一些深入的问题他又答不上来。现在有些程序员为了 DDD 而 DDD ，把自己的代码写成一坨，毫无设计可言，有点本末倒置了

明白 各种技术有各种场景
但 DDD 我好像很少知道有赚钱的公司

指望用 ddd 提高开发效率就是脑子被驴踢了…..

@newaccount #4 我所知道的唯一能拿的出手讲事儿的 DDD 框架，可能就是 Ruby on Rails
这玩意通过动态模型搞了个 Active Record 给别的语言开发人员眼馋坏了
java 有样学样想弄充血模型，通过 AspectJ 搞 compile/load time weaving
嗯，现在很多人都不知道这事儿就说明这玩意早就凉的透透哒

@a949690645 可以展开说说吗？

@littlemis #32 ddd 跟赚钱有啥关系啊，我们公司就是 ddd ，赚钱是销售把软件卖出去就行了