大佬们有 DDD 相关的资料吗？

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

For Existing Member Sign In

• 请不要在回答技术问题时复制粘贴 AI 生成的内容

This topic created in 1961 days ago, the information mentioned may be changed or developed.

最近部门推进 DDD，看了《领域驱动设计》，然后在项目中也运用了大半个月了

最近要求分享下相关的技术知识，我自己也还是懵懂的状态

大佬们有入门相关的演讲的 PPT 或者相关的文章吗？想拿来做参考

ddd

大佬

相关

懵懂

24 replies • 2020-12-18 18:26:07 +08:00

pangleon

Dec 17, 2020

懵懂还能用了半个月?太谦虚了吧。
DDD 实践的项目少的可怜，应该是楼主分享一下。
直接入门 DDD 还是有难度的，可以先了解 ACTIVERECORD 的思想
然后辩证分析 DDD 。

FinnBai

Dec 17, 2020

ThoughtWorks 关于 DDD 的文章 https://insights.thoughtworks.cn/tag/domain-driven-design/

DDD 大佬的博客，有很多有用的文章，写过 DDD 的网书 http://zhangyi.xyz/

DDD china 峰会，各种演讲 http://ddd-china.com/index.html

顺便，我看了这么多文章、书，还有演讲，还是没学好 DDD......

pangleon

Dec 17, 2020

@baiyi 主要是没有实战场景，看过公司一个 DDD 项目的大概，看的心痒痒可是拿不到代码

FinnBai

Dec 17, 2020

Infoq 还出过一本《 DDD quickly 》 https://www.infoq.cn/minibook/domain-driven-design-quickly-new

FinnBai

Dec 17, 2020

@pangleon #3 有道理，好想下一个工作是有充分场景的，能让我实战

attackonFourier

Dec 17, 2020

很多公司缺的不是 DDD 的项目而是真正的领域专家要不然实际开发中还是老的那一套玩法

passerbytiny

Dec 17, 2020 via Android

《实现领域驱动设计》 https://book.douban.com/subject/25844633/ 。虽说是实现，但不是实践，这本书需要学个两三年才能入门。

但既然是工作单位在推，那应该看你工作单位给的资料。如果工作单位没有资料或者虽有但无用，建议马上跑路。

SWALLOWW

Dec 17, 2020

abk?

0bit

Dec 17, 2020

DDD:
Deadline-driven development

hantsy

Dec 17, 2020

没在业务和技术上沉浸 5-10 年，压根就看不懂 DDD 里面的内容。

再说了，DDD 完全是 [ [ [经验和反复实践过程] ] ] ，不是一门像语言和框架一样可以学习的技术，仅仅为了套用 DDD 里面的术语或模式，永远只是在东施效颦。

zhygkx

Dec 17, 2020

张逸在 GitChat 有个专栏《领域驱动设计实践（战略+战术）》，不过我还没看完
https://gitbook.cn/gitchat/column/5cdab7fb34b6ed1398fd8de7

k9982874

Dec 17, 2020

DDD 这玩意有已知的成功项目么？

warush

Dec 17, 2020 via iPhone

我们部门现在的支付系统使用的 ddd，个人感觉真的是工程结构清晰、代码干净，但是我只是应届刚入职不久，如果个人建模的话就一脸懵逼只会在现有模型里搬砖

kkkkkrua

Dec 17, 2020

IDDD 的书里有案例，你可以研究他那个

shyrock

Dec 17, 2020

DDD 目前是一种理念和实践方法论还是说已经有成熟的工具可以实现业务语言到代码的自动映射？

CoderGeek

Dec 17, 2020

写过一段溜了

atpking

Dec 17, 2020

这两天好像 thoughtworks 有 ddd 的一个大会吧楼主可以关注下他们公众号

sha851092391

Dec 17, 2020

DDD 应该分两块理解，一个是战略层面和战术层面。

战略层面其实理解比较好理解，但是要领悟他需要你有很强的业务知识，战略其实就是一种思想指导方法，帮助我们分析业务问题。领域就是一个大的问题（问题域），问题太大不能很好的进行分析，所以需要对问题（领域）进行细分为小问题（子域），如果还是太大就继续再细分，它是指导我们怎么把一个大的领域抽丝剥茧来进行有效分析。（通用语言、Event Storming 可以理解是分析问题的工具）

战术层面其实就是将战略的设计进行落地的手段，“实体、值对象、聚合根、聚合”等都属于战术手段，可以理解为一种设计的模式（可简单类比就是你的代码如何分层设计），而设计模式有很多种，上述的模式可以理解是最佳实践。

上述就是对 DDD 个人的理解，还有一个观点就是可以仅利用 DDD 的战略设计来分析业务，而不一定选择其战术的设计堆项目进行落地。

eic

Dec 17, 2020

有 golang 版的书籍不

faceRollingKB

Dec 17, 2020

个人感觉这个东西没那么复杂，本质上是把项目各个模块分离开来的一种想法，一万个程序员最后就有一万种 ddd

imherer

Dec 17, 2020

@eic 和语言没关系，虽然我们的项目是用的 golang
入门的话可以看看《领域驱动设计》这本书

namelosw

Dec 18, 2020

Eric 那本书很有意思, 但是其实很多都是以探讨的方式展现出来的, 内容也比较老也比较杂, 不建议先看, 读书路线:
《领域驱动设计精粹》 DDDD -> 《实现领域驱动设计》 IDDD -> 《领域驱动设计》 DDD

frandy

Dec 18, 2020

楼主实践 DDD 是从需求到落地，大家都懂才去做的吗，类似 OOP 的概念，程序员自身就能搞定，一直觉得 DDD 没办法光靠代码就行了，这个东西大家都懂才能做，就如上面所说，少个真正的领域专家，如果让程序员去当领域专家，那需求是产品提出，如果让产品去做领域专家，那产品必须懂 DDD 的概念。作为自身是搞开发的，总感觉推行 DDD 是一个集体行为。一些感想，希望各位大佬出来指正。

ldh756034624

Dec 18, 2020

@k9982874 DDD 还是更符合 oop 语言的。现在 java 项目都是披着 oop 的外衣在写面向过程的代码。