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.
Latest comments (0)