:
为了给Javaer落地DDD，我们不得不写开源组件
2024年08月12日 11:40
本文上回书接《这是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那么优雅，但并不影响对建模设计的实现，但“事件的最终一致性”这个组件，我们认为是必不可少的，我们建模最底层的模型就是“命令-事件”模型，没有事件处理的健壮性，意味着最终系统的健壮性无法保障，最终无法满足业务对可用性的要求。
事件的最终一致性
在我们的建模模型中，是在命令处理逻辑中，由领域模型发出事件，而事件如果要在微服务间传递，我们期望达到的效果如下：
- 如果命令处理逻辑成功，即对应的数据库事务提交成功，则确保事件一定能够发出；
- 如果命令处理逻辑失败，即对应的数据库事务回滚，则确保事件一定不发出；
在需求层面，我们并不要求系统确保事件“确定只发一次”，我们知道，这个要求的技术实现难度远远大于前面的两个要求，而且业务可以做幂等处理解决重发的问题。
下图展示了我们csharp版本中关于“命令-事件”的建模实现，以及事务的具体实现：
在我们csharp的版本，我们使用了比较流行的CAP组件，https://github.com/dotnetcore/CAP，这个组件本质上是实现了outbox模式，通常也叫“发件箱模式”，借助这个组件，我们很轻易就实现了对于事件的最终一致性。
下图来自CAP组件的介绍页面，展示了发件箱模式的具体工作原理：
从原理上看，发件箱模式并不是一个复杂的能力，我们认为一向以生态好为优点的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的生态好，但其它语言的生态我认为也都不差，在各自的领域都有非常多的优点。我在各个评论区，总是能看到各种不切实际的偏激言论，感受到种种的恶意。期望各个语言的技术栈从业者，能够更友好地交流，大家都是软件工程师，满足业务需求，实现商业价值，才是大家的更应该关注的。
From:https://www.cnblogs.com/xiaoweiyu/p/18354728
本文地址: http://shuzixingkong.net/article/1020
干系人分析与识别 5W1H 干系人分析与识别 1. 干系人是什么 直接或者间接影响专题，以及被专题影响的人和组织，用户也是属于干系人，是产品直接或者间接的使用者 又叫利益相关者，指积极参与专题或者在专题中其利益可能受积极或消极影响的个人或组织 2. 为什么要分析和识别干系人 找出对专题或者产品有重要
前言 solidworks草图大师，基本的使用过程。 所有的零件基础都是从平面绘制开始，然后凸出来厚度。 本篇绘制一个简单的立方体，熟悉基本操作。 立方体绘制过程 选取一个平面绘制一个立方形，然后拉伸即可。 绘制矩形的方式： 功能所见即所得。 其实用2021版本，还会有动画的提示。（开始以为点进去有
前言 在物联网（IoT）和工业自动化领域，边缘计算设备扮演着至关重要的角色。边缘采集网关作为连接物理世界与数字世界的桥梁，负责收集传感器数据并将数据传输到云端或本地数据中心进行处理。 本文将介绍一款基于 .NET 8 的跨平台高性能边缘采集网关的开源项目。希望通过这个项目能够帮助大家搭建和部署高效的
EF Core 索引器属性（Indexer property）场景及应用 简介 EF Core 中的索引器属性（Indexer Property）是指通过一个特殊的属性来访问实体类中的数据，而不必明确声明实体属性。这种属性在一些动态或未预定义的场景中非常有用，比如当实体的属性名在编译时并不确定，或者
首先看一下效果: 任意控件可以附加一个文字在控件的右上角，并带有红色背景 第一步，新建一个空的wpf项目: 第二步，创建一个类，取名为badge: 第三步，将badge的父类设置成 System.Windows.Documents.Adorner public class Badge : Adorn
大浪淘沙，2024 年的今天，市面上很多监控系统慢慢淡出了大家的视野，而一些新的监控系统也逐渐崭露头角。今天我们就来看看 2024 年的当下，哪些 IT 运维监控系统最值得关注。 Prometheus 毫无疑问，Prometheus 是最值得关注的监控系统，因为 Prometheus 的规范和生态都
前言 接续上一篇的optimizer的学习。 optimizer 代码和上一篇文章的一样，如下: import torch import numpy as np import torch.nn as nn X = torch.tensor([1, 2, 3, 4], dtype=torch.floa
Java中的栈与队列 一、栈（Stack） 1.1 介绍 栈是一种后进先出（LIFO，Last In First Out）的数据结构。在栈中，元素的插入和删除操作都是在栈顶进行的。Java中的java.util.Stack类实现了栈的基本功能，包括push()入栈、pop()出栈、peek()查看栈