V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
shubiao
V2EX  ›  Java

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

  •  
  •   shubiao · 2021-04-05 14:55:31 +08:00 · 4087 次点击
    这是一个创建于 499 天前的主题,其中的信息可能已经有所发展或是发生改变。

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

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

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

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

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

    28 条回复    2021-04-09 17:47:29 +08:00
    zwx327634
        1
    zwx327634  
       2021-04-05 15:13:10 +08:00
    极客时间也有 DDD,但是我没看过
    shubiao
        2
    shubiao  
    OP
       2021-04-05 15:52:32 +08:00
    @zwx327634 去看了一下目录,应该也是概念大于代码的。不过真是奇怪,有 1w+的人学习,DDD 这么火嘛,在网上也没很大的“声音”啊
    Jooooooooo
        3
    Jooooooooo  
       2021-04-05 16:00:22 +08:00
    DDD 是业务驱动的, 大公司的复杂业务才会走到这一步.
    zjlin1984
        4
    zjlin1984  
       2021-04-05 16:25:12 +08:00
    没必要刻意去追求 DDD 吧,解决实际问题就好。
    agdhole
        5
    agdhole  
       2021-04-05 16:58:29 +08:00
    接触的项目里面没有一个项目的规模够得上 DDD
    shubiao
        6
    shubiao  
    OP
       2021-04-05 17:03:45 +08:00
    @zjlin1984 看了下 DDD 的概念还是非常好的,在解决项目的复杂性 /不可维护性问题
    wshcdr
        7
    wshcdr  
       2021-04-05 17:05:58 +08:00
    看那个 ddd_cargo 啊,
    shubiao
        8
    shubiao  
    OP
       2021-04-05 17:06:36 +08:00
    @agdhole 我看了这几天了,理论上来说只要是个企业级的项目,就值得上 DDD
    passerbytiny
        9
    passerbytiny  
       2021-04-05 18:15:39 +08:00
    再认真看一下《实现领域驱动设计》,你就会发现不可能有可以模仿着做的项目教程。DDD 是一种设计思路,并不是方法学。《实现领域驱动设计》本身已经在用真实案例在做演示了,但是你却没法照着模仿,因为业务不一样。
    passerbytiny
        10
    passerbytiny  
       2021-04-05 18:19:11 +08:00
    另外提醒一下,《实现领域驱动设计》作者的主语言是 .NET ,虽然有目的的用 Java 做演示,但是在有些编码习惯上是有出入的。
    shubiao
        11
    shubiao  
    OP
       2021-04-05 20:20:04 +08:00
    @wshcdr 嗯嗯,又去翻了翻 github 看到了。阿里的这个系列也能落地,https://developer.aliyun.com/article/716908
    shubiao
        12
    shubiao  
    OP
       2021-04-05 20:23:45 +08:00
    @passerbytiny 嗯嗯 谢谢。话说看《 IDDD 》真的会一不小心就陷入技术细节里面~ 我是想找一个师傅领进门的项目,把理论实践一下。找到了一两个可以落地的项目了,虽然还是没有详细讲解。链接我上一条贴了,就不重复贴了。
    hantsy
        13
    hantsy  
       2021-04-05 21:05:58 +08:00
    Eric 的 DDD 原书有写代码地址,原来在 sf.net 后也搬到 Github: https://github.com/citerus/dddsample-core/

    实话说,国内的能用 DDD 来做项目的,真的少,可以在 V 站问一下,大部分都是会认为不适合,脱离不了数据库思维,做毛线 DDD 。
    chendy
        14
    chendy  
       2021-04-05 21:20:23 +08:00
    DDD 需要强力专业团,至少需要水平高一些的产品经理,否则就是瞎玩然后玩死
    hantsy
        15
    hantsy  
       2021-04-05 21:31:14 +08:00   ❤️ 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
    charlie21
        16
    charlie21  
       2021-04-05 21:34:57 +08:00   ❤️ 1
    hantsy
        17
    hantsy  
       2021-04-05 21:35:15 +08:00
    @shubiao 指望一个例子搞定 DDD,不可能,DDD 更多的是实践经验,不是一套死模式。如果你软件开发多年,时常会思考怎么去实现更好,我想经过多年经验下来,你根本就不需要 DDD 来指导了。相反,如果仅仅是为了完成任务,跳出结果 ,就是工作 10 年 20 年,看再多的 DDD 书也不会有用。
    hantsy
        18
    hantsy  
       2021-04-05 21:39:07 +08:00
    @chendy 我实在不懂国内的产品经理是做什么的,都是一些无脑的人瞎 JB 想问题, 然后就是要实现。
    而 DDD 需要的是 Domain Expert,需要将问题域的来龙去脉分析的清清楚楚(边界,实体,领域事件等),国内的公司好像根本就没有这个职位。
    crclz
        19
    crclz  
       2021-04-05 22:10:46 +08:00   ❤️ 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 。
    zjlin1984
        20
    zjlin1984  
       2021-04-06 08:30:19 +08:00
    概念好,并一定就是说,要那么做,毕竟只是概念。
    开发过程完全可以忽略这个概念,实事求是解决问题。
    xuanbg
        21
    xuanbg  
       2021-04-06 08:37:37 +08:00
    理解 DDD,有选择地吸收,并应用到项目里面就好。没必要也千万不要去生搬硬套。
    lewis89
        22
    lewis89  
       2021-04-06 09:31:45 +08:00   ❤️ 2
    去看项目代码没有任何意义,领域驱动设计其实都是吸收了现有的软件开发原则例如 SOLID DRY

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

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

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

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

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

    所以共享内核跟界限上下文的根本思想就是 单一职责原则,做开发如果有多年经验的,一般都会把注意力放在建模跟概念最小完整性,这样的系统会更容易维护,至于填空写 CRUD 的人,招几个 2-3 年的年轻人就行了。
    lewis89
        23
    lewis89  
       2021-04-06 09:48:33 +08:00   ❤️ 3
    人月神话里面其实早就指出了,软件开发的困难分为两个

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

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

    2. 本质性困难

    大型系统的概念完整性以及单个系统模块复杂度失控的问题,如果你的系统只是几十个 CRUD 接口,那么你大可不必 费尽周折来设计系统,因为这样的系统,大概 1-2 年后就会被重写,即使重写损失也不大,所以像 DDD 这种设计哲学跟理念,它只能被用在大型系统中,例如像阿里这样的公司,你很难在上百个业务开发团队 建立一个共通的概念模型,例如一个淘宝用户,在各个业务团队中,它所呈现的概念是完全不一样的,只有这样的大系统才有应用 DDD 的价值跟需求
    shubiao
        24
    shubiao  
    OP
       2021-04-06 11:12:33 +08:00
    @crclz 看看 DDD 理念,然后再有真正的代码摆在面前。就知道自己是以前是井底之蛙了,非常感谢你给的例子
    shubiao
        25
    shubiao  
    OP
       2021-04-06 11:25:30 +08:00
    看到确实有不少前辈落地 DDD 的,心里踏实很多,谢谢诸位
    defage
        26
    defage  
       2021-04-06 12:49:29 +08:00
    战术设计这部分其实是很好理解和实践的,当然里面很多细节会因为项目大小、理解程度不同而做成不同的样子。
    在业务架构的层面上,其实战略设计才是 DDD 中更顶层的设计,这块没做好后面战术部分也就走了个形式
    locochen
        27
    locochen  
       2021-04-09 08:14:53 +08:00 via iPhone
    SAP CAP 这个开源项目
    ychost
        28
    ychost  
       2021-04-09 17:47:29 +08:00
    需求明确的情况下 DDD 还是可以,当需求不确定用 DDD 就是作死
    关于   ·   帮助文档   ·   API   ·   FAQ   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   4505 人在线   最高记录 5497   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 32ms · UTC 02:19 · PVG 10:19 · LAX 19:19 · JFK 22:19
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.