After discussing some of my ideas around Event Sourcing at last night’s Elixir Happy Hour in Austin (highly recommend), I spent some time distilling things into a new package called Must.
Event Sourcing provides many technical and business benefits. However, the pitch often starts with technical details that overwhelm newcomers and lead to squabbles about consistency and complexity. I believe there is an opportunity to make Event Sourcing concepts more approachable for teams and leaders who are apprehensive about unfamiliar and intimidating aspects of this technique.
The Goal
Must should make it easier for engineering teams to build Event Sourced systems, with or without prior experience.
Motivation
As much as I feel comfortable using Event Sourcing & CQRS, much of the conversation and tooling feels overly academic. It’s a tough sell.
I also believe the concepts, which are often relegated to finance and highly regulated domains, could become more mainstream given a few modifications to the terminology and technical implementations.
While this package does not use the same verbiage and implementation, it takes inspiration from the first-principles design of the Verbs library for PHP.
The Ask
I am looking for feedback about this approach to ES from anyone who has interest. Please take a look at the documentation and source code. I have a short list of starter questions to get the conversation going:
- Will the Must protocols & behaviour(s) make it easy/easier to spin up Event Sourcing systems?
- Do the words used in the protocols make sense, particularly when they are composed together?
- Which storage adapters are most desired?
- Is this approach doomed to fail?
- Do you have interest in contributing in general or to particular features?
It’s very early, and the picture may not be clear yet how these ideas will pan out. I hope this discussion will help validate the utility of this approach and lead to a strong set of tools for bringing event-sourced systems to life.
