[necovek]

As you implicitly note, message queueing systems like RabbitMQ provide no persistence, and are thus unsuitable as an event store (a database).

Having an event log — the ability to "roll back" — is a crucial feature of event sourcing, so I think you misunderstood the terminology a bit.

However, I do believe it's not your fault: entire DDD terminology is trying to slap big names on already existing concepts in the interest of better/easier communication (there was "journalling" at some point, and RDBMS DBAs used to achieve similar effects with trigger-based history tables), but in my opinion, it has largely failed: people constantly confuse what each of the terms actually is, and digging yourself out of misapplied terminology is even worse.

[raxxorraxor]

Ah, the terminology is indeed completely unfamiliar to me. I didn't understand events for holding persistent data. I was thinking about event busses. I would imagine reconstructing data from a list of event is quite difficult in many circumstances.

[necovek]

If your entire application is based on event sourcing, it's usually not difficult, just slow (which is why the article talks of snapshots as well).

Of course, if you are misusing the pattern, you've got needless complexity no matter how you slice it.