求“领域驱动设计“ Java 项目教程？已全网搜索无果

[shubiao]

听闻了 DDD(领域驱动)的牛，想实践一下。

已看完《领域驱动设计精粹》、看了 50%《实现领域驱动设计》，手头上还有《领域驱动设计》

想找个从搭建项目、分包、建领域模型的视频项目教程学一下真实的编码（不是讲 PPT 概念的），最好是 java

已在 B 站、google 、网易课堂、慕课、腾讯课堂等搜索后无果，这一块国内是不是还属于"蓝海"，教人做项目的视频已经一大堆了

在 github 上找到了一个可能符合预期的，张逸大佬的收费 199，有点小贵。 https://github.com/agiledon/eas-ddd

[zwx327634]

极客时间也有 DDD，但是我没看过

[shubiao]

@zwx327634 去看了一下目录，应该也是概念大于代码的。不过真是奇怪，有 1w+的人学习，DDD 这么火嘛，在网上也没很大的“声音”啊

[Jooooooooo]

DDD 是业务驱动的, 大公司的复杂业务才会走到这一步.

[zjlin1984]

没必要刻意去追求 DDD 吧，解决实际问题就好。

[agdhole]

接触的项目里面没有一个项目的规模够得上 DDD

[shubiao]

@zjlin1984 看了下 DDD 的概念还是非常好的，在解决项目的复杂性 /不可维护性问题

[wshcdr]

看那个 ddd_cargo 啊，

[shubiao]

@agdhole 我看了这几天了，理论上来说只要是个企业级的项目，就值得上 DDD

[passerbytiny]

再认真看一下《实现领域驱动设计》，你就会发现不可能有可以模仿着做的项目教程。DDD 是一种设计思路，并不是方法学。《实现领域驱动设计》本身已经在用真实案例在做演示了，但是你却没法照着模仿，因为业务不一样。

[passerbytiny]

另外提醒一下，《实现领域驱动设计》作者的主语言是 .NET ，虽然有目的的用 Java 做演示，但是在有些编码习惯上是有出入的。

[shubiao]

@wshcdr 嗯嗯，又去翻了翻 github 看到了。阿里的这个系列也能落地，https://developer.aliyun.com/article/716908

[shubiao]

@passerbytiny 嗯嗯 谢谢。话说看《 IDDD 》真的会一不小心就陷入技术细节里面~ 我是想找一个师傅领进门的项目，把理论实践一下。找到了一两个可以落地的项目了，虽然还是没有详细讲解。链接我上一条贴了，就不重复贴了。

[hantsy]

Eric 的 DDD 原书有写代码地址，原来在 sf.net 后也搬到 Github: https://github.com/citerus/dddsample-core/

实话说，国内的能用 DDD 来做项目的，真的少，可以在 V 站问一下，大部分都是会认为不适合，脱离不了数据库思维，做毛线 DDD 。

[chendy]

DDD 需要强力专业团，至少需要水平高一些的产品经理，否则就是瞎玩然后玩死

[hantsy]

上面链接中的 DDD 原书例子(Cargotracker)是用 SpringBoot，Hibernate 写。

其实这个例子，已经被重写成各种版本（不同的语言，框架），Github 上大把。

Eclipse EE4J 官方 Jakarta EE(Java EE 继承者) 也维护了一个 JakartaEE 版本的 CargoTracker 。一个程序熟悉所有的 Java EE 规范（之后再写 Spring 也是不费用吹灰之力），熟悉 DDD 设计理念（完全抛弃数据为中心的设计）。

相比成熟规范和开源框架 Spring，Hibernate 等，这个完全是应用级别，难度系数极低。

https://github.com/eclipse-ee4j/cargotracker

我的 Fork：

https://github.com/hantsy/cargotracker

[charlie21]

看过的关于领域驱动设计的文章
https://www.infoq.cn/article/alibaba-freshhema-ddd-practice
https://insights.thoughtworks.cn/backend-development-ddd

[hantsy]

@shubiao 指望一个例子搞定 DDD，不可能，DDD 更多的是实践经验，不是一套死模式。如果你软件开发多年，时常会思考怎么去实现更好，我想经过多年经验下来，你根本就不需要 DDD 来指导了。相反，如果仅仅是为了完成任务，跳出结果 ，就是工作 10 年 20 年，看再多的 DDD 书也不会有用。

[hantsy]

@chendy 我实在不懂国内的产品经理是做什么的，都是一些无脑的人瞎 JB 想问题, 然后就是要实现。
而 DDD 需要的是 Domain Expert，需要将问题域的来龙去脉分析的清清楚楚（边界，实体，领域事件等），国内的公司好像根本就没有这个职位。

[crclz]

回答楼主：

thoughtworks 的一个 Java DDD 范例项目：
https://github.com/e-commerce-sample/ecommerce-order-service

微软官方的 ddd 教程项目（.Net ）：
https://docs.microsoft.com/en-us/dotnet/architecture/microservices/microservice-ddd-cqrs-patterns/
https://github.com/dotnet-architecture/eShopOnContainers
https://github.com/dotnet-architecture/eShopOnWeb
（虽然是.Net ，但是 AspNet 和 SpringBoot 差别不大）

回复楼上那些说 DDD 不实际、DDD 只适合大公司的复杂业务等说法：
CRUD Boy 无法理解 DDD 属正常现象，但是如果轻视 DDD，那就注定只能当一个低级的 CRUD Boy 。

[zjlin1984]

概念好，并一定就是说，要那么做，毕竟只是概念。
开发过程完全可以忽略这个概念，实事求是解决问题。

[xuanbg]

理解 DDD，有选择地吸收，并应用到项目里面就好。没必要也千万不要去生搬硬套。

[lewis89]

去看项目代码没有任何意义，领域驱动设计其实都是吸收了现有的软件开发原则例如 SOLID DRY

例如六边形架构 其实就是接口隔离原则，它提倡高层次的业务逻辑不要跟低层次技术细节代码耦合，
两者都要依赖接口，例如发送消息到消息队列，从业务层面上来看应该抽象出一个接口，
至于具体怎么发不应该依赖具体的实现例如 kafka 跟 rabbitMQ，这样以后你更换消息中间件不需要改写业务代码，
但是实际上在 CRUD boy 的眼中，耦合什么的都不是问题.. 反正就是 Controller 捅到 Service 跟 DAO 一把梭

例如共享内核跟界限上下文 其实本质上的核心思想就是单一职责原则跟适配器模式，如果你在大型系统中建模，
总想用一个模型概念去解决所有的领域问题，那么你的模型概念就难以理解，
以我上家为例，我们实践 DDD 做了一套护士教育考试系统，但是有的医院硬是要塞进去一个护士排班系统，
这样在建模的时候 就要应用共享内核，

在考试系统上下文我们关心的是护士的职业级别，因为根据一些公立医院的规则
护士通过考试，应该在批准后得到晋升，这样在这个上下文我们关注的是护士的 职业等级相关的属性

在排班系统上下文，我们关注的是护士的工作时长，护士的请假，医院的排班规则等

如果你想建一个大一统的护士模型，那么对不起，这个护士模型没有任何人能理解透，这还是两个系统，
如果再涉及到医院护士 护士长等审批流程系统之类的，那么这个模型的职责会大到你难以理解。

所以共享内核跟界限上下文的根本思想就是 单一职责原则，做开发如果有多年经验的，一般都会把注意力放在建模跟概念最小完整性，这样的系统会更容易维护，至于填空写 CRUD 的人，招几个 2-3 年的年轻人就行了。

[lewis89]

人月神话里面其实早就指出了，软件开发的困难分为两个

1. 非本质性困难
例如 CAP 高并发系统设计 这些都是非本质困难，随着技术进步这些困难早晚都会被解决掉，例如
阿里的 seata 就在解决分布式系统中的分布式事务问题 提供 TCC SAGA 等方案，而这些方案随着技术成熟，未来会越来越对业务层透明，
另外随着一些中间件的成熟，实现可靠消息队列也将不再成为难题，业务层面上不用再需要考虑幂等 消息丢失 异常处理之类的，只要考虑业务上如何设计妥协，因为异步消息系统存在上下文丢失的问题。

在汇编时代，程序员需要自己手动管理栈，在 C 语言时代，程序员需要自己手动管理堆内存，在 C++时代，程序员需要关注 RAII 跟循环引用以及智能指针的引用计数回收模型，在 Java 时代，程序员总算从内存管理中解放出来了，只需要关注业务逻辑了

2. 本质性困难

大型系统的概念完整性以及单个系统模块复杂度失控的问题，如果你的系统只是几十个 CRUD 接口，那么你大可不必 费尽周折来设计系统，因为这样的系统，大概 1-2 年后就会被重写，即使重写损失也不大，所以像 DDD 这种设计哲学跟理念，它只能被用在大型系统中，例如像阿里这样的公司，你很难在上百个业务开发团队 建立一个共通的概念模型，例如一个淘宝用户，在各个业务团队中，它所呈现的概念是完全不一样的，只有这样的大系统才有应用 DDD 的价值跟需求

[shubiao]

@crclz 看看 DDD 理念，然后再有真正的代码摆在面前。就知道自己是以前是井底之蛙了，非常感谢你给的例子

[shubiao]

看到确实有不少前辈落地 DDD 的，心里踏实很多，谢谢诸位

[defage]

战术设计这部分其实是很好理解和实践的，当然里面很多细节会因为项目大小、理解程度不同而做成不同的样子。
在业务架构的层面上，其实战略设计才是 DDD 中更顶层的设计，这块没做好后面战术部分也就走了个形式

[locochen]

SAP CAP 这个开源项目

[ychost]

需求明确的情况下 DDD 还是可以，当需求不确定用 DDD 就是作死