rails_event_store
rails_event_store copied to clipboard
A Ruby implementation of an Event Store based on Active Record
There are situations when firing more instances of event handlers would be problematic. Show how one could achieve this (and there could be multiple ways to achieve it).
Inspiration: amazing SOLID cheat sheet at https://www.monterail.com/blog/solid-principles-cheatsheet-printable
Andrzej told me once how he introduced new developer to RES-backed system. It sounded well-thought and started with defining Command, through Command handler, publishing Events and lastly implementing Event handler,...
If it helps in any way for performance let's brainstorm how we could introduce it.
It's not clear how events are stored (e.g. in a single table? table per event type?). It'd be useful to have such information, for example here https://railseventstore.org/docs/repository/ or in the...
It'd be useful to have a brief glossary/concepts overview in the getting started section, e.g. containing definitions of what event vs command is, what stream is, what is projection, etc....
Currently, in the documentation there's no information about how streams are implemented under the hoods, nor are there any design guidelines. That kind of information would be useful to understand...
https://railseventstore.org/docs/projection/ It's not clear whether projections are in-memory, calculated ad-hoc/at project startup or are somehow persisted. However, having such information would be helpful to understand when to use them.
It might also help clarifying that you can use RES without Rails or even take parts from this ecosystem (`bounded_context`).