这是一个创建于 190 天前的主题，其中的信息可能已经有所发展或是发生改变。
 |
1
MHPSY 2025 年 7 月 8 日
DDD 是什么意思
|
 |
2
v1 2025 年 7 月 8 日  1
@MHPSY Domain-Driven-Design
说白了，就是一切以业务为中心，把业务抽象成公共模块，比如优惠券、支付、购物车 这类，然后增加新业务的时候就像搭积木一样，实现快速搭建、快速投入市场，压缩业务试错的时间成本 |
 |
3
putaozhenhaochi 2025 年 7 月 8 日
2025 之前也没有
|
 |
4
newaccount 2025 年 7 月 8 日 7
DDD 需要深度调研，然后抽象出固定的 domain 模型，后续编码围绕这个固定的 domain 赖构建
天生不适合快速变化的小微企业 简而言之，除业务固定十几年不变的大型国企之外，不要在这个上面浪费时间 而且，Eric Evans 这人除了这本书也没啥实际工程上的指导性开发建议 忽悠了二十多年都搞不起来是有原因的 近期也就是藉着微软的 .net 又死灰复燃继续忽悠，别上当 |
 |
5
illiteracy0001 2025 年 7 月 8 日
越来越感觉 DDD 就是一套新的方法论加现有工具的集合，有用但不是银弹
|
 |
6
qupei2u 2025 年 7 月 8 日
别搞这些，弄得不好就是一坨屎山谁接手谁骂人。弄的好的？没见过！
|
 |
7
siweipancc 2025 年 7 月 8 日 via iPhone
同事用 ai 搭了一套，用起来就是：狗屎。
完全没有工程学的概念，为了涉及而设计，隔两天我就得修个 bug |
 |
8
sks4728 2025 年 7 月 8 日
写的麻烦， 用的难受
|
 |
9
colincat 2025 年 7 月 8 日
2025 年了还在追求这个吗，怎么快怎么来，说不定啥时候代码就扔进垃圾堆了
|
 |
10
skinny 2025 年 7 月 8 日
DDD 这些我就没有看到过正儿八经的好的实践，通常混着一起说的 Clean Architecture 相对简单一点，但是也没有哪个好项目完全遵循，不过其中一些概念相对 DDD 还是好理解些（比如依赖倒置）。你去查，就是一堆简单得不能再简单的 Demo ，但凡较真一点（比如参数验证、Setter 或方法可见性），那些 Demo 里都刻意忽略了那部分示例。
|
 |
11
5261 2025 年 7 月 8 日
我司在用，放眼整个业务群，就只有用了 DDD 开发的业务服务最容易出问题！被骂的也是最多的一个服务也是 DDD 开发的！ 现在交到我手上了，反正是天天问候原来的开发祖宗十八代
|
 |
12
mhycy 2025 年 7 月 8 日 1
设计模式概念很多都是中看不中用的学院派理论，实际上根本没法用。领域驱动，换个熟悉点的名词：微服务。
|
 |
13
hotReady 2025 年 7 月 8 日
有点烦，好多层，就写个增删改查要调好几个地方，而且我们还要写单测，工期又紧，为了设计而设计
|
 |
14
pikko 2025 年 7 月 8 日
稍微了解了一下概念，我觉得，一个概念都这么难懂，还需要全链路的人都理解才能用好这套模式。
那这套模式不就是空中楼阁吗。 |
 |
15
lovejoy 2025 年 7 月 8 日
go 用 ddd ，加个字段，一堆地方得加，效率巨低
|
 |
16
pkoukk 2025 年 7 月 8 日
软件工程没有银弹，100%纯度代表 100%失败
|
 |
17
craftsmanship 2025 年 7 月 8 日 via Android
本菜还以为 DDD 跟 MVC 差不多。。看评论好像并非如此
|
 |
18
littlemis OP 我也是草台班子做法 没用过 DDD🤣
|
 |
19
a949690645 2025 年 7 月 8 日
我在用，感觉挺不错的。
|
 |
20
YVAN7123 2025 年 7 月 8 日
DDD 感觉就是刷 KPI
 |
 |
21
SuperManNoPain 2025 年 7 月 8 日
只能说改东西巨麻烦，中小厂还是最好别碰
|
 |
22
helloworldgo 2025 年 7 月 8 日 1
组织架构适合 DDD 么，不适合别搞
|
 |
23
wu00 2025 年 7 月 8 日 1
特别屎，要是再叠加没有分离团队的“微服务”就更屎了
|
 |
24
lawrencexu 2025 年 7 月 8 日
统一语言这个提法和实践还是挺好的，跟业务之间能够减少分歧和误解，方便建立正确的业务模型。至于其他的缺乏工程实践的标准，很难推广。
|
 |
25
karmaisbitch 2025 年 7 月 8 日
上一任技术负责人推了两年 ddd ，最后拿了大礼包跑路了
|
 |
26
526457385 2025 年 7 月 8 日
DDD 只在写 demo 的时候很成功
|
 |
27
guyeu 2025 年 7 月 8 日 2
我倒是觉得 DDD 是软件工程里一个在敏捷开发的基础上搞出来的一个好理论，很适合研发占比高的初创团队。
说白了就是混淆业务和程序的界线，产品经理也是开发者，开发者也是测试人员，大家拥有同一套业务知识，团队的组织架构、微服务的模块划分和领域对象的限界达成一种统一。 很多技术负责人主推的 DDD 有点戴着镣铐跳舞，产品、测试人员可能还停留在瀑布式开发的工作方式，技术主推的 DDD 就会变成一种编码层面的内耗，在这种团队里，开发人员作为需求的下游，往往既要协调上游产品的思路，依靠不完整的领域知识去硬套，又要处理下游测试人员的反馈，属实是夹板气。 但是部分思路或者设计模式，比如领域建模、事件驱动，还是值得学习，并应用在具体的工程实践中的。 |
|
28
mhycy 2025 年 7 月 8 日
严格说 DDD 在不合适的编码场景，不合适硬用结果不好用，是现在很多 DDD 方案让人难受的根源。
DDD 本质上不是一个开发范式，是一个思路，是一个解耦思路。 不理解思路硬要在软件工程上用不合适的东西实现，那是学院派没事找事。 开个地图炮：JAVA 开发者最爱干这事。 |
|
29
mhycy 2025 年 7 月 8 日
区块链的链本身就是 DDD 范式的最好体现，这一点所有区块链都是 DDD 的成功案例。
链本身只关注交易，只关注行为，并不关注结果，结果是基于全链计算得到的。 这就是 DDD 让事情的变化通过事件记录进行解耦的抽象过程。 按这个往外推，其实很多时候就已经用到 DDD 的思路了。 |
 |
30
EvanPan 2025 年 7 月 8 日
感觉最好就是在产品设计和拆分微服务的时候指导用用，拆分后的微服务开发就按照正常来比较合适
|
 |
31
hippieZhou 2025 年 7 月 8 日 via iPhone
我觉得很搞笑的是，有些人写了一些看似是分层的代码就自认为是采用了 DDD ，但是当你问他一些深入的问题他又答不上来。现在有些程序员为了 DDD 而 DDD ，把自己的代码写成一坨，毫无设计可言，有点本末倒置了
|
|
32
littlemis OP 明白 各种技术有各种场景
但 DDD 我好像很少知道有赚钱的公司 |
 |
33
zvcs 2025 年 7 月 9 日
指望用 ddd 提高开发效率就是脑子被驴踢了…..
|
|
34
newaccount 2025 年 7 月 9 日
@newaccount #4 我所知道的唯一能拿的出手讲事儿的 DDD 框架，可能就是 Ruby on Rails
这玩意通过动态模型搞了个 Active Record 给别的语言开发人员眼馋坏了 java 有样学样想弄充血模型，通过 AspectJ 搞 compile/load time weaving 嗯，现在很多人都不知道这事儿就说明这玩意早就凉的透透哒 |
 |
35
bisyao 2025 年 7 月 9 日
@a949690645 可以展开说说吗？
|
Select Language