如何快速理解并掌握 DDD 后端开发？

用一年时间，重构项目十几次，慢慢理解 DDD 中的每个含义，就会了，DDD 几乎都是抽象概念，短时间不可能掌握。

先成为业务专家

没必要非 DDD ，就像没必要非微服务一样。我用自己设计的独立服务，可微服务可单体可混。

我还以为是 data driven development

Deadline Driven Development !

想要落地和掌握 DDD ，需要：
1. 项目业务足够复杂：简单项目不是不能 DDD 但是相当于大炮打蚊子性价比差
2. 需求方对自己的业务有准确深入的认识：否则做的设计和业务实际情况和发展对不上，等于白做
3. 开发团队足够强力：开发脑子不够用理解不了领域模型一切白费

DDD 解决了什么痛点？如果你们业务开发没有能用 DDD 解决的痛点 非要上 DDD ，那不是没事找事吗

先去找个使用 DDD 设计思想设计的后端框架，看看人家的架构设计。
在照着使用这个框架的开源项目照猫画虎，然后一步一步来，其中每次遇到自己不明白的设计元素和设计模式的时候就去网络上搜索此设计的作用。（这可以让你从战术上快速学会 DDD).
战略上就慢慢来吧，业务复杂后，为了管理项目的复杂性，你也会自己刻意向 DDD 的设计靠近。另外如果使用微服务，你会天然用子域和事件驱动的模式去设计，很容易就会逐步靠近 DDD 的领域驱动设计思想。
另外有多余的实践，下面几本书都可以看看。
<<领域驱动设计: 软件核心复杂性应对之道>>
<<实现领域驱动设计>>
<<微服务架构设计模式>>

另外再说一点，DDD 和微服务的设计都需要负担额外的成本，如果项目可以用简单的 CURD 或单体架构，就不要用 DDD 和微服务模式，DDD 成本还没那么高，毕竟你也可以用 DDD 来设计一个巨大的单体，但微服务就不一样了，分布式服务要面对的复杂性和一致性问题需要非常高的额外成本负担。

有时候多想想 为啥要 DDD ，项目有多复杂才需要用到

有一天，看到一篇技术架构，明确的表明，使用了 DDD 。
仔细一看，MVC 、贫血/充血、以及接口模块的领域。
嗯，确实用了 DDD ，但仿佛又没用到

DDD 说白了就是基于业务概念进行设计开发，而 MVC 是基于数据流。DDD 我只推荐 Domain modeling made functional

@isnullstring 很多时候都是瞎搞的，DDD 说实话 有用肯定是有用，关键是国内大环境就是 搞快点 再继续搞快点，能跑就行，
DDD 这种设计 反倒成为累赘，

其实软件工程说白了，不管是什么技术，软工的目的 就是降低单位模块的复杂性，让复杂性可控 并收缩在一块，毕竟人脑子不是 RAM 可以装下整个程序上下文，像我司 一个车辆状态属性，在 不知道多少个模块 有多少个地方 被 update 过，且又不知道多少模块 又依赖这个属性，软工几乎就没有，大家讲业务纯粹就靠硬拼记忆力，有的时候真的很心累，改一个地方，得看好多个地方，不知道前任写的时候，有多少骚操作，在某个地方 又做了一些奇怪的操作

我觉得 DDD 可能最关键的是你这个业务得是个成熟稳定的业务，不要求低成本快速开发，要求系统稳定，才比较适合用 DDD ，比如造飞机、金融这种；

其次你得维护一个 DDD 的设计团队，因为实际 DDD 现在并没有金标准，其中细节、流程都得你们自己有统一定义和解释并且展开培训；

反正挺麻烦的，普通企业或者业务实在没必要；

14 楼中肯，领导理解了或自以为理解了 ddd ，开始强推，手下一堆月薪 7 、8 千不到的一年经验大白菜怎么推动？

恰巧我最近也有这个疑问，也在学习 DDD 这个主题，可以交流一下
推荐两个我关注的 B 站 up 主

https://space.bilibili.com/6733407
https://space.bilibili.com/24690212

DDD 非常复杂，并且需要对于进行很明确的业务概念的梳理，这点在很多国内的公司比较难。

1. 由于你问的是 C#，微软官方有一套 DDD 介绍： https://learn.microsoft.com/en-us/dotnet/architecture/microservices/microservice-ddd-cqrs-patterns/ddd-oriented-microservice

2. 阿里技术专家详解 DDD 系列 https://zhuanlan.zhihu.com/p/340911587 ，是一个系列，强烈推荐。

我在针对我们团队业务和当时的情况，调研一段时间后，放弃了 DDD ，转为整洁架构一套，算是对于 DDD 的一种简化版本。有做 Golang 开发的可以一起讨论： https://github.com/xpzouying/go-clean-arch?tab=readme-ov-file

在我看来，DDD 是一种设计，让你如何去规划这个系统，比如我们在使用微服务的时候，如何决定一个服务到底有多大，能做多少事情，它的边界在哪里，这个就可以用 DDD 来解决，比如我们在做单体服务的时候，如果有两个 service 需要业务上循环依赖，怎么去把它俩的依赖解开，确定每个 service 到底该干那些事。

DDD 是教你怎么去做做设计，不是写两个 command 、domain 就叫 DDD ，贫血/充血什么的只是具体的工具，我经常问别人，现在我们系统是基于面向过程语言编写的，它没有对象模型这种，它就不配用 DDD 了？

记得前几年看过一个大佬这样描述 DDD 的：DDD 是战略，贫血/充血是战术。

可以看一篇 infoq 的文章“DDD 和微服务之间是什么关系？”
DDD 的本质是一种软件设计方法，而微服务架构是具体的实现方式。微服务架构虽好，但是他并没有给出如何对复杂系统进行分解的具体方法论，而 DDD 正好就是解决方案。
https://www.infoq.cn/article/34uhkxy98uztabz_mpui

在一些崇倡极简的语言中，类似 Sofa 这种固化了项目工程结构的框架是很少见到的，比如 Go 语言。
在 Go 语言中写一个 Web 系统，达到一定复杂度之后，经常会像无头苍蝇一样遇到不知道怎么组织目录结构的问题。其实这个时候 DDD 是一种很好的方法论支撑 。
我不赞成全盘引入 DDD ，因为对于不同复杂度的系统来说，需要的抽象等级也不一样，简单来说，有的时候我的系统没那么复杂，所以引入一堆概念完全没有必要。
对于 DDD 可以根据实际需要循序渐进的引入系统设计中，我写了一个简单的 Go 语言 DDD Web 程序模版，麻雀虽小五脏俱全，同时也符合 DDD 的基本概念，可以作为 Go 小型 Web 项目的参考。
https://github.com/elliotxx/go-web-template

也是 golang ，贴个 DDD 框架，我们老大自己写的 https://github.com/8treenet/freedom

这个东西感觉只适合复杂业务，简单的直接 mvc 一把梭就是了

DDD 的核心是业务模型划分, 编码实现模式从针对流程编码, 变更为针对模型编码.
划分整个业务, 梳理内部模型层次和同其他业务边界, 使得项目整体复杂度可控.
针对模型实现, 充血/贫血, CQRS, MVC 等等, 按照实际情况来. 不要生搬硬套.

美团技术公众号有几篇 DDD 落地的文章可以看下。关于统一语言、厘清概念和编码规则都很有启发。

根据业务一点点的迭代重构到 ddd 才能更好的理解它

@powerman #13 对的，也不是说完全反对 DDD ，更应该是因地制宜

互联网三大毒瘤，DDD 、中台、低代码