It was an interesting time to go through this experiment. The goal was to reimplement Ruby experiment in python. Then to check which approach is interesting to use in production projects.
I reimplemented 7/10 of them. Here is the list:
I didn’t see much benefit from yield and Popo. This two seemed like a similar solution to others without any extra benefits. DCI is interesting, but I can’t just copy Ruby version. I would need to use some hacks. To implement it correctly I would need to read about DCI and think about how to implement it in Python.
Looking at the functional example I prepared a monadic one. It’s still in pull request cause I’m not an expert in mondas, so probably I’ve done some mistakes.
Evaluation criteria
For evaluation, I asked myself some questions:
- Is it easy to understand?
- Is it easy to maintain on bigger scale?
- Is it framework agnostic?
- Is aggregate aware that event-sourcing was used?
My Top 3
Aggregate Root
Polymorphic / Duct Typing
Exposed Queries
I would recommend starting with the standard Aggregate Root approach. Is well known and default approach in every framework and tutorial. Its downsides are easily maintainable.
Personally, I liked the polymorphic approach best, but production implementation would need a little change to apply events separately from processing commands. It’s a must-have with event-sourcing if we want to change processing logic later.
The functional/monadic approach is interesting, but I don’t know how to change it to process commands separately from applying events without complicating it a lot.
One more about framework
I was very disappointed with the python event-sourcing framework.
From one perspective it’s a big framework with many integrations. But its implementation is coupling your project with this framework. There are traps in this framework like aggregate mutation implemented in domain events. Or mapping of events and DB entries is based on python path, so if you will refactor your code it will break on reading from DB. Also, it appears to be a well-documented framework, but documentation is only describing implementation choices without explaining why it’s like this (for example why execution code is in domain event class).
Of course, it’s a big framework and by digging it you can hack it and change the default behaviour in many places. But this is a lot of work to just get something that should be a default behaviour like in other languages (for example Rails Event Store).
I would recommend avoiding this framework. Implementing your own foundation for event store is not so much work or you can seek for simpler and lighter implementation that will suit your needs.