There’s quite a lot to read and learn about if you’re going to take on these patterns (plural because they are distinct from one another, despite being used together most of the time). I would suggest that you move cautiously in your first couple of attempts to apply them and learn some lessons in an application you’re ok with rewriting once or twice until you get the hang of it.

On ES: If you are comfortable with how GenServers work, you are 90% of the way toward grasping the mechanics of this architectural pattern. Imagine that while receiving messages as a GenServer you persist them before applying them—this is the essence of ES. To be sure, its somewhat of an oversimplification—for example, if you decide that your messages need to change format or payload in some way, its a simple matter to update the sender and receiver, while with ES your “receiver” (aka projection in ES parlance) will have to live with those messages for potentially long periods of time. So modelling your domain events correctly becomes far more important, as does understanding the notion of a boundary and what it means to have coupled code. If you get this part badly wrong, you’re going to have some long-lived headaches. On the upside, however, you also will find that having stored the events you are now free to have as many representations of your data as you need, and that you can generate them retrospectively quite easily (provided you captured the data in the first place.)

On CQRS: I have to confess I’m of the opinion that this one doesn’t make a lot of sense in Elixir. CQRS was meant as a stepping stone towards ES (a decidedly functional data pattern) for object-oriented developers and code. Thus, there is a lot of emphasis placed on terminology like “aggregate root” which is no different from any other state you would build up in a GenServer. So I think that CQRS can actually be counterproductive in that it adds additional conceptual layers on top of things that Elixir already does very well natively, which is confusing for newcomers as well as developers experienced in using CQRS from other platforms. Command messages as an artifact of code are needed in most OO languages because (Smalltalk notwithstanding) they don’t tend to model messaging as a first-class notion; command handlers are similarly modelled very easily with pattern matching and process registries.

On frameworks: There are a few I’m aware of in Elixir-land, with @slashdotdash’s work being the furthest along, at least as far as I am aware. I think if you are going to implement these patterns and you want to use a framework, they are a good choice with an API that makes sense most of the time. However, as noted above, I think Elixir/OTP gives you the tools already to implement these patterns out of the box, with the exception perhaps of a robust eventstore (which has additional requirements beyond simply being a database of events). I would consider carefully whether the additional dependencies are worth the cost.

Getting help/learning more: There are not a lot of high quality books on applying ES in particular that I’ve found useful, and the ones that look most interesting to me are generally either aimed at Akka, .Net, or using Kafka. One book I think every developer ought to have on principle here is Enterprise Integration Patterns, which is basically a book on messaging patterns. The other somewhat required reading is the DDD “Blue Book”. You don’t HAVE to use DDD with event sourcing, but most people I think find understanding some of the essential notions to be invaluable in determining stream boundaries. Especially given that Phoenix appears to be trending in this direction, its worthwhile reading anyway.

The DDD/CQRS google group is good to read and lurk in, and the community there is generally helpful. We also have a slack channel dedicated to eventsourcing on the elixir slack, and there is a whole slack dedicated to it as well with many of the folks from the google group active on it.

Good luck with your explorations on this!

@rrevanth I gave a talk to a local user group on Thursday evening covering this topic. Unfortunately it wasn’t recorded, but I’ve published the slides online.

You might find them useful too. Let me know if you have any questions.

The puzzling thing is that you identify the pattern but not the project - which is basically is like asking whether a particular answer is appropriate for some unknown question. So is the true objective your personal project or finding a project to learn more about CQRS/ES?

When it comes to CQRS/ES I like to stick close to the source. Martin Fowler’s CQRS:

Greg Young was the first person I heard talking about this approach - this is the summary from him that I like best.

So for example Greg Young - CQRS and Event Sourcing - Code on the Beach 2014 and Greg Young - A Decade of DDD, CQRS, Event Sourcing (and for good measure Greg Young - The art of destroying software).

Bryan Hunter - CQRS with Erlang (github) could also be of interest.