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

[shubiao]

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

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

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

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

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

[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 就是作死