这是一个创建于 1435 天前的主题，其中的信息可能已经有所发展或是发生改变。
最近部门推进 DDD，看了《领域驱动设计》，然后在项目中也运用了大半个月了
最近要求分享下相关的技术知识，我自己也还是懵懂的状态
大佬们有入门相关的演讲的 PPT 或者相关的文章吗？ 想拿来做参考
最近要求分享下相关的技术知识，我自己也还是懵懂的状态
大佬们有入门相关的演讲的 PPT 或者相关的文章吗？ 想拿来做参考
 |
1
pangleon 2020-12-17 09:19:09 +08:00  1
懵懂还能用了半个月?太谦虚了吧。
DDD 实践的项目少的可怜，应该是楼主分享一下。 直接入门 DDD 还是有难度的，可以先了解 ACTIVERECORD 的思想 然后辩证分析 DDD 。 |
 |
2
baiyi 2020-12-17 09:21:07 +08:00 3
ThoughtWorks 关于 DDD 的文章 https://insights.thoughtworks.cn/tag/domain-driven-design/
DDD 大佬的博客，有很多有用的文章，写过 DDD 的网书 http://zhangyi.xyz/ DDD china 峰会，各种演讲 http://ddd-china.com/index.html 顺便，我看了这么多文章、书，还有演讲，还是没学好 DDD...... |
|
4
baiyi 2020-12-17 09:23:31 +08:00
Infoq 还出过一本 《 DDD quickly 》 https://www.infoq.cn/minibook/domain-driven-design-quickly-new
|
 |
6
attackonFourier 2020-12-17 09:29:58 +08:00 3
很多公司缺的不是 DDD 的项目 而是真正的领域专家 要不然实际开发中还是老的那一套玩法
|
 |
7
passerbytiny 2020-12-17 09:43:35 +08:00 via Android 1
《实现领域驱动设计》 https://book.douban.com/subject/25844633/ 。虽说是实现，但不是实践，这本书需要学个两三年才能入门。
但既然是工作单位在推，那应该看你工作单位给的资料。如果工作单位没有资料或者虽有但无用，建议马上跑路。 |
 |
8
SWALLOWW 2020-12-17 09:59:29 +08:00 1
abk?
|
 |
9
0bit 2020-12-17 11:05:34 +08:00
DDD:
Deadline-driven development |
 |
10
hantsy 2020-12-17 11:17:01 +08:00 1
没在业务和技术上沉浸 5-10 年，压根就看不懂 DDD 里面的内容。
再说了，DDD 完全是 [ [ [经验和反复实践过程] ] ] ，不是一门像语言和框架一样可以学习的技术，仅仅为了套用 DDD 里面的术语或模式，永远只是在东施效颦。 |
 |
11
zhygkx 2020-12-17 11:53:33 +08:00 1
张逸在 GitChat 有个专栏《领域驱动设计实践（战略+战术）》，不过我还没看完
https://gitbook.cn/gitchat/column/5cdab7fb34b6ed1398fd8de7 |
 |
12
k9982874 2020-12-17 12:48:49 +08:00
DDD 这玩意有已知的成功项目么？
|
 |
13
warush 2020-12-17 14:09:20 +08:00 via iPhone
我们部门现在的支付系统使用的 ddd，个人感觉真的是工程结构清晰、代码干净，但是我只是应届刚入职不久，如果个人建模的话就一脸懵逼 只会在现有模型里搬砖
|
 |
14
kkkkkrua 2020-12-17 14:32:42 +08:00
IDDD 的书里有案例，你可以研究他那个
|
 |
15
shyrock 2020-12-17 14:48:33 +08:00
DDD 目前是一种理念和实践方法论还是说已经有成熟的工具可以实现业务语言到代码的自动映射？
|
 |
16
CoderGeek 2020-12-17 14:58:14 +08:00
写过一段溜了
|
 |
17
atpking 2020-12-17 15:10:19 +08:00 1
这两天好像 thoughtworks 有 ddd 的一个大会吧 楼主可以关注下他们公众号
|
 |
18
sha851092391 2020-12-17 15:20:48 +08:00 1
DDD 应该分两块理解，一个是战略层面和战术层面。
战略层面其实理解比较好理解，但是要领悟他需要你有很强的业务知识，战略其实就是一种思想指导方法，帮助我们分析业务问题。领域就是一个大的问题（问题域），问题太大不能很好的进行分析，所以需要对问题（领域）进行细分为小问题（子域），如果还是太大就继续再细分，它是指导我们怎么把一个大的领域抽丝剥茧来进行有效分析。（通用语言、Event Storming 可以理解是分析问题的工具） 战术层面其实就是将战略的设计进行落地的手段，“实体、值对象、聚合根、聚合”等都属于战术手段，可以理解为一种设计的模式（可简单类比就是你的代码如何分层设计），而设计模式有很多种，上述的模式可以理解是最佳实践。 上述就是对 DDD 个人的理解，还有一个观点就是可以仅利用 DDD 的战略设计来分析业务，而不一定选择其战术的设计堆项目进行落地。 |
 |
19
eic 2020-12-17 18:36:46 +08:00
有 golang 版的书籍不
|
 |
20
faceRollingKB 2020-12-17 19:04:26 +08:00
个人感觉这个东西没那么复杂，本质上是把项目各个模块分离开来的一种想法，一万个程序员最后就有一万种 ddd
|
 |
22
namelosw 2020-12-18 09:41:41 +08:00 1
Eric 那本书很有意思, 但是其实很多都是以探讨的方式展现出来的, 内容也比较老也比较杂, 不建议先看, 读书路线:
《领域驱动设计精粹》 DDDD -> 《实现领域驱动设计》 IDDD -> 《领域驱动设计》 DDD |
 |
23
frandy 2020-12-18 11:54:46 +08:00 1
楼主实践 DDD 是从需求到落地，大家都懂才去做的吗，类似 OOP 的概念，程序员自身就能搞定，一直觉得 DDD 没办法光靠代码就行了，这个东西大家都懂才能做，就如上面所说，少个真正的领域专家 ，如果让程序员去当领域专家，那需求是产品提出，如果让产品去做领域专家，那产品必须懂 DDD 的概念。作为自身是搞开发的，总感觉推行 DDD 是一个集体行为。一些感想，希望各位大佬出来指正。
|
 |
24
ldh756034624 2020-12-18 18:26:07 +08:00
@k9982874 DDD 还是更符合 oop 语言的。现在 java 项目都是披着 oop 的外衣在写面向过程的代码。
|
Select Language