[boothead]

I always think that event sourcing is missing the concept of commands.

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.

[jpatte]

The concept of commands is very useful but I don't think it belongs to the event sourcing pattern. Event sourcing is just a way to write and read data, it doesn't say anything about how you process inputs and how that processing can lead to a change of data. For that concern there exist other patterns like CQRS which introduces the concept of command. These patterns are complementary, and using both CQRS + ES is actually common practice.