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

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

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

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

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

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

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

看那个 ddd_cargo 啊，

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

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

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

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

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

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

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

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

上面链接中的 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

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

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

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

回答楼主：

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 。

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

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

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

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

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

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

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

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

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

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

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

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

2. 本质性困难

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

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

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

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

SAP CAP 这个开源项目

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