基线信息: 我正在使用外部OAuth提供程序进行登录.如果用户登录到外部OAuth,则可以进入我的系统.但是,我的系统中可能尚不存在此用户.这不是一个真正的技术问题,但我正在使用JOliver EventStore来实现它的价值.
逻辑:
问题: 假设在读取模型更新之前以某种方式发出了两个创建命令,这是由于浏览器刷新或在实现与读取模型的一致性之前发生的一些其他异常.没关系,这不是我的问题.
会发生什么: 因为新ID是Guid梳子,事件存储器不可能知道这两个CreateUser命令代表同一个用户.当他们到达读取模型时,读取模型将知道(因为他们具有相同的电子邮件)并且可以合并两个记录或采取一些其他补偿操作.但是现在我的阅读模型与事件存储不同步,事件存储仍然认为这些是两个独立的实体.
也许这无关紧要,因为:
任何人都能说明他们如何处理类似的问题吗?如果需要进行某些补偿操作,那么当读取模型服务意识到它有重复的条目时会发出某种补偿命令吗?有没有更简单的方法我不考虑?
谢谢!
你非常接近我认为适当的解决方案.如果我可以总结一下,这个场景有点像这样:
现在,不要在读取模型中合并记录,为什么不向您的域模型发送ResolveDuplicateVisitorEmailAddress {Key1,Key2},将其留给域模型(要采取的业务决策的编码形式)来解决此问题.您甚至可以使用专用的读取模型来处理这类问题,另一个读取模型只会获得一种DuplicateVisitorEmailAddressResolved事件,并将其投影到正确的记录中.
警告:您已经问了一个技术问题,我给了您一个技术上可行的解决方案.一般情况下,我不会应用这种技术,除非我有一些业务指标值得投资(用户首次同时登录的频率是多少 - 也许以这种方式解决它只是忽略根本原因的一种方式(flakey OAuth,没有注册新访客流程等)).这个问题有其他技术解决方案,但我想给你一个最接近现有的解决方案.它们的范围从顺序注册新访问者到保留读取模型中尚未访问的访问者的内存中投影.