My tribute to Domain Events

BY ANDERS LEMKE-HOLSTEIN // JANUARY 26, 2021 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 data¹ 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 book². 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 stranger³, 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 that⁴. Ryan Singer says you should⁵. 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.

‘Real’ Programming Is an Elitist Myth ⤴
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. ⤴
In chapter 3 of Shape Up Ryan Singer argues that if something doesn’t feel right, you should walk away. Let time help you. In this case, it’s not time, but a new abstraction that will help you. ⤴