In the last article we discussed on the scenario where you know what events you should receive, just not the order. But what if you don't know that? That's the question I got from Ben, let's answer that today and explain how using revisions can help you in reaching strict ordering.
Wow, I didn't expect a whole article, thanks Oskar! In our case we are building a new system beside the existing system, and syncing all changes made in the existing system to our new system. This is why we have internal/domain events coming in. So I appreciate that you continued the article with some possible solutions.
Happy to help, Ben! Curious if you see that what I outlined here can be helpful in your case, or if there are some other concerns?
For instance, I know that adding revision or reshaping events is not always viable, but then we need to learn to live with the imperfect world and e.g. think more about compensating operations when events arrive after we made our internal translation.
Yes, the revision concept plus storing "pending" commands would meet our needs. The only tricky part is that there can be changes in the source system that we don't care about in the target system. If we increment the revision for these changes but the target system doesn't subscribe to those events, our revision is no longer gapless in the view of the target system. So we would either need to
- only increment the revision # if it's a relevant event (I don't care for the coupling this adds)
- Handle every event in the target system. If it's one we don't care about, we still update our revision number. We end up doing some extra processing here, but seems acceptable for solving the problem.
Wow, I didn't expect a whole article, thanks Oskar! In our case we are building a new system beside the existing system, and syncing all changes made in the existing system to our new system. This is why we have internal/domain events coming in. So I appreciate that you continued the article with some possible solutions.
Happy to help, Ben! Curious if you see that what I outlined here can be helpful in your case, or if there are some other concerns?
For instance, I know that adding revision or reshaping events is not always viable, but then we need to learn to live with the imperfect world and e.g. think more about compensating operations when events arrive after we made our internal translation.
Yes, the revision concept plus storing "pending" commands would meet our needs. The only tricky part is that there can be changes in the source system that we don't care about in the target system. If we increment the revision for these changes but the target system doesn't subscribe to those events, our revision is no longer gapless in the view of the target system. So we would either need to
- only increment the revision # if it's a relevant event (I don't care for the coupling this adds)
- Handle every event in the target system. If it's one we don't care about, we still update our revision number. We end up doing some extra processing here, but seems acceptable for solving the problem.