I just lost too much time with ORMs before, and I’ll try to avoid them in future.

The first thing that came to me as a real back-end alternative was to think with events. And after all, if it is just like that for humans, why this couldn’t be the same for computers.

When I see my sister, I have memories M therefore point of view A, about her. And one day, I’ll probably have memories M + ∆M, therefore point of view B, about her. Memories won’t change drastically (M ≃ M + ∆M). Points of views sometimes will (A != B).

That's for normal and sound people: they register events in, without any on-the-fly treatment:
a) objectively see what’s going on.
b) register it in your brain.
c) make your conclusion from it afterwards.
d) change your conclusion.
e) f) g) … no limit for changing your conclusion.

Dictators do a bit more stupid thing:
a) see what’s going on there a way that fits to your already existing conclusion.
b) register it in your brain.
c) love your conclusion because your memories are magically close to what you thought! Don’t change this wonderful conclusion.

ORMs are dictators. With them, you’ll modelize your entities (tables, joins, etc.) to fit your current needs. At first, it will be a fairy tale, because it would be made for what you would be currently coding. But, the more you will code with it afterwards and the more your app will gain in weight, the more you will lose your time with a stubborn megalomaniac monster that will compel you to fit your code to its stuck structure, the way it sees the data.

That’s how the couple EventSourcing + CQRS really emerged. The big companies were suffocating because they realized recruited engineers just served as maintenance workforce on trying to change the monster’s point of view : that is, in short, trying to migrate data from databases to databases, with the delusion that each new database would be the brand-new ultimate modelization of a (in constrast) continually growing app inner logic.

So, we store what occurs neutrally, with no treatment at all, and then project events into read views (also known as projections). MySQL, Redis, Elasticsearch, OrientDB... you're free to choose the types of read models you need. For example, if my API is of GraphQL kind, I could make Redis projections for lightning fast querying. But if I also need exports in bulk from my BackOffice, I could make MySQL exhaustive joined-tables-like projections, ready to be read as they are. Projections are progressively made: when an event is appended to the EventStore, they're immediately updated. And one day, I could decide to completely change how the projections are designed (change the tables names in MySQL one, add an OrientDB projection, remove the Redis one, etc.). Remember: Memories won’t change (events). Points of view will (projections).

I’ll not introduce or explain anything in details, but I advise you to supervise what I talk about here (there's a growing enthusiasm for EventSourcing on the web), it could properly change your next coder life moments.

When I first coded an EventSourcing + CQRS app, I felt like being able to ride a bike as a child.