|
|
|
|
|
|
by jpatte
4148 days ago
|
|
|
I'm currently in the process of redesigning the whole server architecture of our SaaS application to embrace event sourcing - we were using a classic relational database until now. I'm excited by all the new possibilities this will give us, but it's a lot of work to rewrite just about everything and to migrate old data into event streams. My advice to anyone who considers event sourcing for future projects: use it from the beginning. Transitioning from a more traditional model is hard. Btw, the author seems to make a confusion between events and commands. These are not the same thing: a command represents an action (by the user, an other system or an internal process), while an event represents a change in the data. A command may generate 1 or several events during its processing. It is not saved in a data store, but it can be replayed in case of failure if retry policies are in place. |
|
|
If you have the idea of commands (which I think are mentioned in some of the literature) it becomes a lot easier. Commands are intensions to change the world that might fail, and have access to the current state when they are executed. If they succeed when they're run, they will emit events. Doing it like this means that you are guaranteed a sane event stream, and it makes it much easier to map from an existing system to events.
I've written both a web scraper and a database exporter that works in this way: as the legacy system is traversed you try to run commands. If the command succeeds and produces events you know that the events are compiant with your business logic. If the command fails you have the option to fail the whole operation or continue without the parts of the old system that don't meet your business logic.
edit updated as you mentioned commands above.