为了给Javaer落地DDD，我们不得不写开源组件

故事背景

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那么优雅，但并不影响对建模设计的实现，但“事件的最终一致性”这个组件，我们认为是必不可少的，我们建模最底层的模型就是“命令-事件”模型，没有事件处理的健壮性，意味着最终系统的健壮性无法保障，最终无法满足业务对可用性的要求。

事件的最终一致性

在我们的建模模型中，是在命令处理逻辑中，由领域模型发出事件，而事件如果要在微服务间传递，我们期望达到的效果如下：

1. 如果命令处理逻辑成功，即对应的数据库事务提交成功，则确保事件一定能够发出；

2. 如果命令处理逻辑失败，即对应的数据库事务回滚，则确保事件一定不发出；

在需求层面，我们并不要求系统确保事件“确定只发一次”，我们知道，这个要求的技术实现难度远远大于前面的两个要求，而且业务可以做幂等处理解决重发的问题。

下图展示了我们csharp版本中关于“命令-事件”的建模实现，以及事务的具体实现：

在我们csharp的版本，我们使用了比较流行的CAP组件，https://github.com/dotnetcore/CAP，这个组件本质上是实现了outbox模式，通常也叫“发件箱模式”，借助这个组件，我们很轻易就实现了对于事件的最终一致性。

下图来自CAP组件的介绍页面，展示了发件箱模式的具体工作原理：

从原理上看，发件箱模式并不是一个复杂的能力，我们认为一向以生态好为优点的Java生态，也一定有类似且流行的组件，很不幸的是，我们在互联网以及能够触达的Java圈子里调研一番之后，得出了如下结论：

1. Java生态有关于分布式事务的实现，例如：JEE，JBoss等，但目前基本没有团队在用了；

2. Java生态没有现成的类似CAP这样的组件可以开箱即用；

上述结论仅表示我们目前的认知和信息渠道，如果有大佬能够给指个路，不甚感激！

cap4j

基于前面的结论，为了实现Java项目的DDD代码体验实践，我们开源了一个cap4j项目，期望能将CAP项目的能力移植到Java生态，项目地址：https://github.com/netcorepal/cap4j

该项目目前实现了JPA+RocketMQ的组合，我们规划在未来支持更多的ORM和MQ中间件，同时也会支持与CAP组件的协议兼容，以实现Java、dotnet异构架构的进一步融合。也欢迎大家为项目贡献代码和想法。

最后

关于技术生态这件事，可以说Java的生态好，但其它语言的生态我认为也都不差，在各自的领域都有非常多的优点。我在各个评论区，总是能看到各种不切实际的偏激言论，感受到种种的恶意。期望各个语言的技术栈从业者，能够更友好地交流，大家都是软件工程师，满足业务需求，实现商业价值，才是大家的更应该关注的。