Who am I?

Hi! If you are here, you stumbled upon my LinkedIn profile, where I promoted this series. You probably came here from Substack (if not, please subscribe to get all the updates just in time).

I'm a passionate developer who has this crazy idea (yet not so "disruptive") to log the building of a full example of event sourcing, from event storming to the depiction of aggregates and the event store from scratch. I've zero academic learnings; all I know is what I learned on the field and writing tons of lines of code.

I'm one of the founders of Plannix.co and here I develop mostly the backend as CTO.

Why this series?

This series comes out after a 12-month-long study of how to implement this technology in our startup.

I've iterated this project at least 6 times, starting every time from scratch, so you are peaking inside a long (and most nightly) journey. Please be patient if you find antipatterns or mistakes. It's an exploration of a random tech guy, not the Bible of Event Sourcing. So take it as what it is: an exploration. Not a manual or a guide

What is my goal?

I'd like to pass the concepts why I felt in love with this architecture because once the set up is done, its advantages are countless.

What we are building

Well, I hate examples that involve To-Do lists, because this kind of domain is too simple to tackle the complexity of read models or aggregates. So I stepped out and looked at what I liked most except coding. And I found that poetry is a good field.

We'll build a backend for hypothetical software that has to manage the poetry slam events worldwide. Using concepts like poets, MCs, games, turns voting, and tournaments.

If you don't know what a poetry slam is, feel free to have a basic knowledge of this great form of expression and living poetry following this link: POETRY SLAM

How long will be this series?

Well, I don't know. I have jotted out a scheme in Obsidian and it looks like at least 46 articles. I'm writing this first one to get committed and make some noise about it. It will be a technical journal where I'll try to explain the reasons why I made certain choices and leave to the Internet some experience I never found in my exploration. I hope this series will help you have better knowledge, reuse some of my code, and enjoy the painful architecture from scratch, with the sweats and swears of a common dev that felt in love with code and working systems.

I encourage you to comment and engage in the conversation any time you want, I think confrontation is always a great value in the developer's community and indeed I love the motto of rough consensus.

I love the running code, not my ideas per se. So, come abroad and let's talk.

There will be a GitHub repo that will be updated alongside the publishing of articles.
Find my GH profile HERE