rrevanth
I recently came accross this pattern where he created event driven elixir app.
I am planning a personal project and stuck on the pattern to adopt. Want some opinions on CQRS/ES pattern.
It seems awesome but wanted opinion from you guys ![]()
Trending in Discussions
Hey there,
It’s been more than a year since we started using LiveView as our main UI library and building a whole library of UI componen...
New
I am happy to introduce the very α version of the new programming language compiled to BEAM.
Welcome Cure.
It has literally three kille...
New
Hi everyone!
The first release candidate for the Expert language server project is now available!
We’ve published a press release detai...
New
A little off-topic, but I feel like people here have a good head on their shoulders.
I used to be quite good at making software. Was luc...
New
Hi there! :wave:
@frigidcode and I (but mostly him) have been running an Elixir Book club, we’re almost done with Designing Elixir Syste...
New
I’ve been using Emacs as my main code editor for more than a two years. It’s a custom build version although I’ve tried doom emacs and sp...
New
I love Elixir. It’s one of 2 programming languages I’ve ever fallen in love with.
But I don’t use it anymore.
Serverless was the promis...
New
Other Trending Topics
Edit: 2026 May 15 - This post is archived.
Mob is alive!!
Main docs: mob v0.7.11 — Documentation
A bit of explanation for the slightly c...
New
Hey, I’m Jesse and I’m the main contributor behind Dexter, a full-featured, lightning-fast Elixir LSP optimized for large codebases. It s...
New
Hobbes is a low-level distributed database for the Elixir programming language.
Hobbes provides a simple, safe, and scalable storage lay...
New
ExRatatui lets you cook up rich terminal UIs in Elixir, powered by Rust’s ratatui via Rustler NIFs. Build interactive terminal applicatio...
New
Just published claude-code-elixir, a plugin marketplace for Claude Code with Elixir support. These are the plugins I’ve been using for my...
New
Xamal is a deployment tool for Elixir apps that deploys native releases to bare metal servers over SSH. It’s a port of GitHub - basecamp/...
New
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #library
- #deployment
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #elixirconf
- #channels
- #exunit
- #discussion
- #code-sync
- #podcasts
- #javascript
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ai
- #ecto-query
- #elixirconf-us
- #blog-post
- #elixir-ls
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #elixirconf-eu
- #api
- #forms
- #metaprogramming
- #hex











Showing Posts 1 to 7- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
karmajunkie
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!
slashdotdash
@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.
slashdotdash
Implementing Domain-Driven Design by Vaughn Vernon is a good book for the practical application of CQRS when building an app. All the source code and examples are in Java, but don’t let that put you off too much.
rrevanth
Thank you for this. I had some hard time wrapping my head around the pattern from that!
This gives me some head start.
rrevanth
Awesome. Thank you!
peerreynders
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:
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.
rrevanth
Sorry. I did not phrase my sentences correctly. I wanted to know more about the pattern as it seemed interesting while reading through it .
So, I thought of doing a small project with the pattern but wanted to get some insights about it prior.