听闻了 DDD(领域驱动)的牛，想实践一下。
已看完《领域驱动设计精粹》、看了 50%《实现领域驱动设计》，手头上还有《领域驱动设计》
想找个从搭建项目、分包、建领域模型的视频项目教程学一下真实的编码（不是讲 PPT 概念的），最好是 java
已在 B 站、google 、网易课堂、慕课、腾讯课堂等搜索后无果，这一块国内是不是还属于"蓝海"，教人做项目的视频已经一大堆了
在 github 上找到了一个可能符合预期的，张逸大佬的收费 199，有点小贵。 https://github.com/agiledon/eas-ddd
 |
1
zwx327634 Apr 5, 2021
极客时间也有 DDD，但是我没看过
|
 |
3
Jooooooooo Apr 5, 2021
DDD 是业务驱动的, 大公司的复杂业务才会走到这一步.
|
 |
4
zjlin1984 Apr 5, 2021
没必要刻意去追求 DDD 吧，解决实际问题就好。
|
 |
5
agdhole Apr 5, 2021
接触的项目里面没有一个项目的规模够得上 DDD
|
 |
7
wshcdr Apr 5, 2021
看那个 ddd_cargo 啊，
|
 |
9
passerbytiny Apr 5, 2021
再认真看一下《实现领域驱动设计》，你就会发现不可能有可以模仿着做的项目教程。DDD 是一种设计思路，并不是方法学。《实现领域驱动设计》本身已经在用真实案例在做演示了，但是你却没法照着模仿，因为业务不一样。
|
|
10
passerbytiny Apr 5, 2021
另外提醒一下，《实现领域驱动设计》作者的主语言是 .NET ，虽然有目的的用 Java 做演示，但是在有些编码习惯上是有出入的。
|
 |
11
shubiao OP @wshcdr 嗯嗯，又去翻了翻 github 看到了。阿里的这个系列也能落地，https://developer.aliyun.com/article/716908
|
|
12
shubiao OP @passerbytiny 嗯嗯 谢谢。话说看《 IDDD 》真的会一不小心就陷入技术细节里面~ 我是想找一个师傅领进门的项目，把理论实践一下。找到了一两个可以落地的项目了，虽然还是没有详细讲解。链接我上一条贴了，就不重复贴了。
|
 |
13
hantsy Apr 5, 2021
Eric 的 DDD 原书有写代码地址，原来在 sf.net 后也搬到 Github: https://github.com/citerus/dddsample-core/
实话说，国内的能用 DDD 来做项目的，真的少，可以在 V 站问一下，大部分都是会认为不适合，脱离不了数据库思维，做毛线 DDD 。 |
 |
14
chendy Apr 5, 2021
DDD 需要强力专业团，至少需要水平高一些的产品经理，否则就是瞎玩然后玩死
|
|
15
hantsy Apr 5, 2021  2
上面链接中的 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 |
 |
16
charlie21 Apr 5, 2021 1
|
|
17
hantsy Apr 5, 2021
@shubiao 指望一个例子搞定 DDD，不可能，DDD 更多的是实践经验，不是一套死模式。如果你软件开发多年，时常会思考怎么去实现更好，我想经过多年经验下来，你根本就不需要 DDD 来指导了。相反，如果仅仅是为了完成任务，跳出结果 ，就是工作 10 年 20 年，看再多的 DDD 书也不会有用。
|
|
18
hantsy Apr 5, 2021
@chendy 我实在不懂国内的产品经理是做什么的，都是一些无脑的人瞎 JB 想问题, 然后就是要实现。
而 DDD 需要的是 Domain Expert，需要将问题域的来龙去脉分析的清清楚楚（边界，实体，领域事件等），国内的公司好像根本就没有这个职位。 |
 |
19
crclz Apr 5, 2021 2
回答楼主：
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 。 |
|
20
zjlin1984 Apr 6, 2021
概念好，并一定就是说，要那么做，毕竟只是概念。
开发过程完全可以忽略这个概念，实事求是解决问题。 |
 |
21
xuanbg Apr 6, 2021
理解 DDD，有选择地吸收，并应用到项目里面就好。没必要也千万不要去生搬硬套。
|
 |
22
lewis89 Apr 6, 2021 2
去看项目代码没有任何意义，领域驱动设计其实都是吸收了现有的软件开发原则例如 SOLID DRY
例如六边形架构 其实就是接口隔离原则，它提倡高层次的业务逻辑不要跟低层次技术细节代码耦合， 两者都要依赖接口，例如发送消息到消息队列，从业务层面上来看应该抽象出一个接口， 至于具体怎么发不应该依赖具体的实现例如 kafka 跟 rabbitMQ，这样以后你更换消息中间件不需要改写业务代码， 但是实际上在 CRUD boy 的眼中，耦合什么的都不是问题.. 反正就是 Controller 捅到 Service 跟 DAO 一把梭 例如共享内核跟界限上下文 其实本质上的核心思想就是单一职责原则跟适配器模式，如果你在大型系统中建模， 总想用一个模型概念去解决所有的领域问题，那么你的模型概念就难以理解， 以我上家为例，我们实践 DDD 做了一套护士教育考试系统，但是有的医院硬是要塞进去一个护士排班系统， 这样在建模的时候 就要应用共享内核， 在考试系统上下文我们关心的是护士的职业级别，因为根据一些公立医院的规则 护士通过考试，应该在批准后得到晋升，这样在这个上下文我们关注的是护士的 职业等级相关的属性 在排班系统上下文，我们关注的是护士的工作时长，护士的请假，医院的排班规则等 如果你想建一个大一统的护士模型，那么对不起，这个护士模型没有任何人能理解透，这还是两个系统， 如果再涉及到医院护士 护士长等审批流程系统之类的，那么这个模型的职责会大到你难以理解。 所以共享内核跟界限上下文的根本思想就是 单一职责原则，做开发如果有多年经验的，一般都会把注意力放在建模跟概念最小完整性，这样的系统会更容易维护，至于填空写 CRUD 的人，招几个 2-3 年的年轻人就行了。 |
|
23
lewis89 Apr 6, 2021 3
人月神话里面其实早就指出了，软件开发的困难分为两个
1. 非本质性困难 例如 CAP 高并发系统设计 这些都是非本质困难，随着技术进步这些困难早晚都会被解决掉，例如 阿里的 seata 就在解决分布式系统中的分布式事务问题 提供 TCC SAGA 等方案，而这些方案随着技术成熟，未来会越来越对业务层透明， 另外随着一些中间件的成熟，实现可靠消息队列也将不再成为难题，业务层面上不用再需要考虑幂等 消息丢失 异常处理之类的，只要考虑业务上如何设计妥协，因为异步消息系统存在上下文丢失的问题。 在汇编时代，程序员需要自己手动管理栈，在 C 语言时代，程序员需要自己手动管理堆内存，在 C++时代，程序员需要关注 RAII 跟循环引用以及智能指针的引用计数回收模型，在 Java 时代，程序员总算从内存管理中解放出来了，只需要关注业务逻辑了 2. 本质性困难 大型系统的概念完整性以及单个系统模块复杂度失控的问题，如果你的系统只是几十个 CRUD 接口，那么你大可不必 费尽周折来设计系统，因为这样的系统，大概 1-2 年后就会被重写，即使重写损失也不大，所以像 DDD 这种设计哲学跟理念，它只能被用在大型系统中，例如像阿里这样的公司，你很难在上百个业务开发团队 建立一个共通的概念模型，例如一个淘宝用户，在各个业务团队中，它所呈现的概念是完全不一样的，只有这样的大系统才有应用 DDD 的价值跟需求 |
|
25
shubiao OP 看到确实有不少前辈落地 DDD 的，心里踏实很多，谢谢诸位
|
 |
26
defage Apr 6, 2021
战术设计这部分其实是很好理解和实践的，当然里面很多细节会因为项目大小、理解程度不同而做成不同的样子。
在业务架构的层面上，其实战略设计才是 DDD 中更顶层的设计，这块没做好后面战术部分也就走了个形式 |
 |
27
locochen Apr 9, 2021 via iPhone
SAP CAP 这个开源项目
|
 |
28
ychost Apr 9, 2021
需求明确的情况下 DDD 还是可以，当需求不确定用 DDD 就是作死
|
Select Language