本文上回书接《这是DDD建模最难的部分(其实很简单)》,欢迎关注我的同名公众号。 https://mp.weixin.qq.com/s/HZKMLF0_I10iczzp2mAR-w
故事背景
2013年中,我们的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的版本,我们使用了比较流行的CAP组件,https://github.com/dotnetcore/CAP,这个组件本质上是实现了outbox模式,通常也叫“发件箱模式”,借助这个组件,我们很轻易就实现了对于事件的最终一致性。 下图来自CAP组件的介绍页面,展示了发件箱模式的具体工作原理: 从原理上看,发件箱模式并不是一个复杂的能力,我们认为一向以生态好为优点的Java生态,也一定有类似且流行的组件,很不幸的是,我们在互联网以及能够触达的Java圈子里调研一番之后,得出了如下结论:
- Java生态有关于分布式事务的实现,例如:JEE,JBoss等,但目前基本没有团队在用了;
- Java生态没有现成的类似CAP这样的组件可以开箱即用;