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