I hadn’t originally planned on making another framework, at least initially. Elixir lends itself to ES so well that many don’t believe a framework is required and only adds another layer of abstraction. As you pointed out, so much is already provided by Elixir and OTP. I believe that whilst another framework probably isn’t a good idea, a library or at least a thorough guide on implementing ES from scratch could provide that simple introduction. Additional features (and complexity) could be added as the project required.
After a good amount of time going over Commanded’s code, I certainly couldn’t implement a simpler framework - in use or design - than @slashdotdash already has without sacrificing flexibility and sensible design decisions. I must say that the docs and codebase are so easy to follow and pull apart.
One thing I had considered was following a similar structure to Commanded & EventStore where the two are separate apps with a clearly defined API between them. That way they could share resources, with my memory image implementation being able to use EventStore and Commanded being able to use my file based alternative. Not sure if there would be much point, but it feels like it would be worth doing.
I totally agree that an “ES-lite” framework that’s as simple and modular as Ecto would be a wonderful thing, but I’m not sure how to go about it. ES almost by necessity requires CQRS - they aren’t as independent as many claim - which is where the complexity ramps up. Perhaps someone (smarter than me) writing up an in-depth guide to ES in Elixir is the real solution here?
EDITED TO ADD: Ben’s work on the Building Conduit book not withstanding of course. Without that I wouldn’t have been able to grok ES at all, but I had to learn Conduit to learn Commanded to learn ES, so perhaps a pure Elixir version something similar?