escray
看了开篇词，再加上 Thoughtworks 的背书，感觉这个专栏还是比较有吸引力的，打算跟着专栏更新的节奏学习一下。极客时间之前还有一个 《DDD实战课》的专栏，可以互为参照。
作者回复：欢迎学习，有问题一起讨论哈。
2022-12-06
掂过碌蔗
我发现ddd解决了很多我现在项目中遇到的问题
2024-03-09
听水的湖
置顶
同学们好，我是编辑小新。
迭代一配套代码已整理到GitHub，希望同学们好好利用，觉得不错别忘了给老师点个Star。
代码链接：https://github.com/zhongjinggz/geekdemo
另外，钟老师近期翻译了《领域驱动设计参考》。项目地址：https://github.com/zhongjinggz/ddd-reference-cn ；电子书地址：https://zhongjinggz.github.io/ddd-reference-cn/#/ 。 通过这本小册子，可以快速一览DDD全貌。同学们可以作为课后拓展阅读资料使用，有什么翻译不准确，或者不好理解的地方也欢迎提出。
2024-02-19
Geek_53c57c
老师深入浅出，以前做的项目用到了DDD，对于项目的架构设计一直理解的不到位。看了老师的课，受益匪浅。
作者回复：多谢，共同进步！
2023-10-12
HeM
我有几个疑惑想问下老师，还请帮忙解惑一下：
1.事件风暴的基于背景是什么，是基于系统流程还是业务流程，也就是说，事件风暴的事件是系统中会产生的事件，还是业务中会产生的事件？
比如说“合同已签订”，我觉得是站在业务的角度来说的，因为不会在系统签订合同，系统只能是录入签订好的合同，站在系统角度来说就是“合同已添加”。
那么同理“客户已添加”是站在系统角度来说的，业务不会说添加了一个客户吧，那么我就感觉“客户已添加”和“合同已签订”所基于的角度不同。
2.客户是什么时候绑定客户经理的，合同是什么时候绑定销售人员的，为什么在事件风暴里没体现出来，只有更换客户经理和更换销售人员
作者回复：非常好的问题！
1. 事实上，事件风暴既可以表示单纯的业务流程，也可以表示系统流程。而本课程中将事件风暴用于软件需求的探索，所以本课程中确实讲的是系统流程。但是我们又强调用业务语言，所以准确地说，是“用业务语言表达业务人员对系统的期望”。比如说“合同已签订”这个业务语言，实际上表达的是要在系统中表示“合同已签订”这个事实。
另一方面，如果说“客户已添加”是站在系统角度的话，那么您认为站在业务角度应该怎么说呢？（用您的答案替换掉“客户已添加”这个说法就解决了）
2.在分析业务的时候，可以问业务人员，客户的添加和绑定客户经理是否可以分开做，比如先添加客户（但不绑定客户经理），之后再绑定客户经理。如果是这样的话，那么就分成两个事件。但如果业务需求是两件事情必须同时发生，那么就作为一个事件“客户已添加”（隐含着绑定了客户经理）。这就是本文的做法。如果想再说清楚一点，可以用业务规则的形式说明。
2023-12-07
1
下吧下吧我要发芽
1、目的不是为了开发微服务，而是一种解决复杂软件设计的方法（从需求、服务拆分）；
当然在微服务的拆分过程中，参考DDD的领域建模之后进行领域的拆分，同时知道分层分域；
2、DDD有着二十多年的时间，是在工程实践过程中总结出来的一种模式、方法，当然随着软件行业的发展，他也在逐步的换发新的生命，有创新，但不是从无到有的发明创新。
作者回复：非常好！
2023-12-13
🏄🏻米兰的大铁匠🎤🎈
第二遍学习有了更透彻的理解，读老师的文章温故知新
编辑回复：欢迎在留言区多分享你的思考收获，加油～
2023-12-24
末日，成欢
对识别领域事件还有点困惑
本文中对领域事件的定义是, 业务流程已经发生的那些事。
因为我在本文中对领域事件的理解, 领域事件主要还是从业务流程中已经发生的事情中提取一些关键信息的, 后续用来做建模用的，可能还是有点类似传统的软件工程中提取需求的理解。
而我在其他资料说看到的是, 领域事件发生通常会导致进一步的业务操作, 它们用领域事件来解耦, 关注侧重点就不一样，它有这个含义吗？
还有一些问题
1.假如说用户在网上购买了一本书, 如果我想对这个流程进行建模, 最终的领域事件是说商品已下单还是说订单已支付, 我们关注是最终的业务流程结果, 还是只要是有意义的业务流程结果？ 如果存在多个中间业务结果, 是不是每个中间的业务流程也算事件, 只不过最终的是一个大事件？
2.假设一些领域实体, 它们本身业务逻辑不复杂, 就是简单的读取数据,落表这种的, 领域层还有必要吗？
3.假设某个业务流程中, 需要使用7/8个领域实体, 并且这个流程业务规则很复杂, 比如A业务规则还需要依赖3-4个领域实体,是不是搞一个领域服务,在这种做逻辑？
作者回复：首先，原文中，领域事件是“业务过程中，业务人员要关注的那些已经发生的事儿”。你的引用中漏了关键的“业务人员要关注的”这几个字。
理解这几个字，就会发现，和你说的“通常会导致进一步的业务操作”并不矛盾。这么想：为什么业务人员要关注呢？一个主要原因就是通常会导致进一步的业务操作。
注意，上面说的是从理解业务（或者是需求分析）的角度来说的。而“解耦”则是从架构设计的角度来说的，注意区分。
根据前面说的，可以回答另外3个问题：
1. 到底是“商品已下单”和“订单已支付”两个事件还是最终的一个事件，要看业务是不是关注这两个事件，业务觉得区分两个事件是否有意义。
2. 这不是要不要领域层的问题，而是要不要使用领域驱动设计的问题。其实各有利弊，需要权衡，没有唯一答案。
3. 如果这些规则不适合放在某一个实体里面处理，或者开发人员使用的是贫血模型，那么就搞一个领域服务；否则不用领域服务。
2023-08-24
扶程星云
非常感谢老师的分享，第一次读完，很多地方懵懂，我会不断重复拜读佳作！
作者回复：共同进步！
2023-07-28
1
aoe
置顶
第二次学习总结：
1. 从全局视角找出「大功能模块」
2. 在「大功能模块」中找出「子功能」
3.「子功能」推荐以一级列表平铺呈现，可以降低复杂度（反例见需求二），更利于分析问题
详见文章末尾「图例说明」https://wyyl1.com/post/23/06/
2023-07-10
1
无问
钟老师 golang有什么参考的ddd项目吗
作者回复：我对Go不是很熟，可以参考下面的文章：
https://mehdihadeli.github.io/awesome-go-education/ddd/
https://programmingpercy.tech/blog/how-to-domain-driven-design-ddd-golang/
https://www.calhoun.io/moving-towards-domain-driven-design-in-go/
2023-06-21
讲师
钟敬
Thoughtworks 首席咨询师、数字化转型与运营团队 DDD 负责人
编辑推荐
看过的人还看了
