New Recording on Event modelling anti-patterns from DDDEU

Welcome to the new week!

I’m always saying that with Event-Driven Architecture, the effort pays back.

That goes both ways: the less effort we put in, the more it’ll hurt later.

There’s a wide range of issues you may be facing, from overfocusing on the state instead of tracking behaviour, to asking others more often than allowing them to tell you what happened, and ending with race conditions and other unpleasant scenarios.

I packed as many of such cases into our talk, and the recording from this year’s DDD Europe just arrived:

During the session, I explained the specifics of event modelling (yes, no capital letter, and double l), starting with bad practices and knowing why and how to avoid them.

I told the story about the project that aimed to modernise legacy software into the event-driven world. In theory, artificial, but in practice, none of the examples were made up. Either I made those mistakes on my own, or I saw them in my projects or helped to fix them for my clients.

I tried to make it both entertaining and educational, bitter and sweet. It is not easy when you’re not a native speaker. There’s a thin line between being funny and being silly.

There’s also a thin line between bad and good practices. And its name is: context.

Also, as much some of those cases may seem wild, then I can assure you that all of those mistakes I either:

• did by myself,

• saw in my projects,

• saw in my client’s project.

Check it out, why learn always from your mistakes? Learn from mine.

The talk also summarised my article series about anti-patterns in event modelling. Here’s the full list:

• State Obsession,

• Property Sourcing,

• I’ll just add one more field.

• Clickbait event,

• Should you record multiple events from business logic?,

• Stream ids, event types prefixes and other event data you might not want to slice off.

Check also more general considerations:

• Events should be as small as possible, right?,

• What’s the difference between a command and an event?,

• Internal and external events, or how to design event-driven API,

• Event Streaming is not Event Sourcing!,

• Don’t let Event-Driven Architecture buzzwords fool you,

• How to design software architecture pragmatically,

• How to deal with privacy and GDPR in Event-Driven systems.

And hey, I’m also doing consulting and mentoring. If you’re struggling with your projects/organisation with such cases, I’m happy to help. Feel free to reach out to me through the email.

Cheers!

Oskar

p.s. Ukraine is still under brutal Russian invasion. A lot of Ukrainian people are hurt, without shelter and need help. You can help in various ways, for instance, directly helping refugees, spreading awareness, and putting pressure on your local government or companies. You can also support Ukraine by donating e.g. to Red Cross, Ukraine humanitarian organisation or donate Ambulances for Ukraine.