为了给Javaer落地DDD,我们不得不写开源组件
本文上回书接《这是DDD建模最难的部分(其实很简单)》,欢迎关注公众号(老肖想当外语大佬),加群、获取最新文章更新和DDD框架源码,视频和直播在B站。
https://mp.weixin.qq.com/s/HZKMLF0_I10iczzp2mAR-w
![](https://img2024.cnblogs.com/blog/62928/202408/62928-20240813115919797-1724995065.jpg)
故事背景
2023年中,我们的Java后端团队为了落地DDD,全面引入了dotnet技术栈,具体过程和成果,可以看我的B站频道《Java8 到 .NET8,团队升级报告 - 第二弹》https://www.bilibili.com/video/BV14YgYedE1f
在近半年的时间,我将自己落地DDD的实践经验进行提炼和总结,以公众号文章和B站视频的方式分享出来,与更多的网友建立链接和交流,得到了很多肯定反馈,也因为大家提供的视角,使得我自己对DDD的认知有了更深层次的迭代。
目前我们借助dotnet强大的生态以及csharp优良的语言设计,已经可以非常丝滑地用代码表达模型和业务,整个软件交付的体验和效率,获得了前所未有的进步。我们netcorepal-cloud-framework框架在这个过程中也得到了进化和可用性验证,我们坚信找到了一套更加务实的软件设计认知和方法论。
Javaer太难了
由于我们团队实际上还是Java和csharp双技术栈,于是我们萌生了一个想法,是否可以让我们的Java项目交付过程也如此地丝滑?带着这个想法,我们开始在Java生态中寻找可以帮助我们构建出类似csharp框架效果的组件:
- Web框架: aspnetcore vs springboot
- ORM:EntityFrameworkCore vs JPA
- 中介者模式:MediatR vs ?
- 事件的最终一致性实现:CAP vs ?
其中“中介者模式”和“事件的最终一致性”实现我们没有找到合适的替代品,经过分析,“中介者模式”并不是必须的,虽然最终实现起来,没有csharp那么优雅,但并不影响对建模设计的实现,但“事件的最终一致性”这个组件,我们认为是必不可少的,我们建模最底层的模型就是“命令-事件”模型,没有事件处理的健壮性,意味着最终系统的健壮性无法保障,最终无法满足业务对可用性的要求。
事件的最终一致性
在我们的建模模型中,是在命令处理逻辑中,由领域模型发出事件,而事件如果要在微服务间传递,我们期望达到的效果如下:
- 如果命令处理逻辑成功,即对应的数据库事务提交成功,则确保事件一定能够发出;
- 如果命令处理逻辑失败,即对应的数据库事务回滚,则确保事件一定不发出;
在需求层面,我们并不要求系统确保事件“确定只发一次”,我们知道,这个要求的技术实现难度远远大于前面的两个要求,而且业务可以做幂等处理解决重发的问题。
下图展示了我们csharp版本中关于“命令-事件”的建模实现,以及事务的具体实现:
![](https://img2024.cnblogs.com/blog/62928/202408/62928-20240812123901768-1455984495.png)
在我们csharp的版本,我们使用了比较流行的CAP组件,https://github.com/dotnetcore/CAP,这个组件本质上是实现了outbox模式,通常也叫“发件箱模式”,借助这个组件,我们很轻易就实现了对于事件的最终一致性。
下图来自CAP组件的介绍页面,展示了发件箱模式的具体工作原理:
![](https://img2024.cnblogs.com/blog/62928/202408/62928-20240812141959092-918458861.png)
从原理上看,发件箱模式并不是一个复杂的能力,我们认为一向以生态好为优点的Java生态,也一定有类似且流行的组件,很不幸的是,我们在互联网以及能够触达的Java圈子里调研一番之后,得出了如下结论:
- Java生态有关于分布式事务的实现,例如:JEE,JBoss等,但目前基本没有团队在用了;
- Java生态没有现成的类似CAP这样的组件可以开箱即用;
上述结论仅表示我们目前的认知和信息渠道,如果有大佬能够给指个路,不甚感激!
cap4j
基于前面的结论,为了实现Java项目的DDD代码体验实践,我们开源了一个cap4j项目,期望能将CAP项目的能力移植到Java生态,项目地址:https://github.com/netcorepal/cap4j
该项目目前实现了JPA+RocketMQ的组合,我们规划在未来支持更多的ORM和MQ中间件,同时也会支持与CAP组件的协议兼容,以实现Java、dotnet异构架构的进一步融合。也欢迎大家为项目贡献代码和想法。
最后
关于技术生态这件事,可以说Java的生态好,但其它语言的生态我认为也都不差,在各自的领域都有非常多的优点。我在各个评论区,总是能看到各种不切实际的偏激言论,感受到种种的恶意。期望各个语言的技术栈从业者,能够更友好地交流,大家都是软件工程师,满足业务需求,实现商业价值,才是大家的更应该关注的。