Why I love them so much, and why you should too.
BY ANDERS LEMKE-HOLSTEIN // event driven architectures // programming
Would you be able to identify “the silver bullet” if you held it in your hand? Probably not, right? It doesn’t matter, though, as it probably doesn’t exist. But still, would you?
Paul Ford argues that developers has a tendency to devalue data1 and the storing of data. It’s kind of ironic then, that our main vocabulary, the building blocks we use, are defined by a very popular data storage mechanism: Relational databases. Create. Read. Update. Destroy. Has many. Belongs to.
We are so tied up in all the wonderful things relational databases has been giving us. Transactions. Foreign keys. We think it’s the way to define data. We use it to model our domains. Thinking in UML. Thinking in CRUD.
It’s so ingrained that after 4 years of working on an event driven platform, I still find myself using that vocabulary, even when I don’t have to.
What a straitjacket.
“But what’s the alternative?” Great question. I’m so happy you asked. The alternative is Domain Events.
Imagine turning everything you learned upside down. Or inside out if you will.
What is a Domain Event?
I first learned about Domain Events in Eric Evans legendary book2. But the shortest way I can possibly describe what a Domain Event is, is this:
Something happened, that somebody cares about.
A few examples of events from a domain I work in:
- Article published
- Membership activated
Without even describing the domain, I’m sure you intuitively can see that somebody must care about those events.
How beautiful it is, when the fundamental building blocks of the domain, the software, are that relatable. Think about it. If this is relatable to you, a random stranger3, how relevant must this feel to someone who actually has skin in the game?
It can feel daunting. Letting go. You might even miss your straitjacket. Where should you put your arms? They feel awkward when they just dangle. But actually, you are removing some resistance. And that’s a good thing. You should follow the path of least resistance. Niklas Luhman did that4. Ryan Singer says you should5. And they are wise humans worth listening to.
Sure, it comes with some other challenges. But until now, for me at least, they have all been solvable.
Domain-Driven Design: Tackling Complexity in the Heart of Software provides a groundbreaking way of tackling software architecture and development. ⤴
A very cherished stranger that is! ⤴
Sönke Ahrens describes how Niklas Luhman, one of the most productive academics in history, would only work on what felt easy, in How to Take Smart Notes. ⤴