Image for post
Image for post
Photo by Kazuo ota on Unsplash

It’s been 8 years since I first sat on the more comfortable side of the recruitment table. I was a developer and my team needed more of my kind. I might have been more stressed than some of the candidates. I took a long time to prepare, reading over and over through the CVs and crafting the interview questions for each candidate.

Now, hundreds of interviews later, I’m a lot more comfortable and efficient at talking to potential colleagues. What hasn’t changed is that I only have an hour to learn about the candidate and only their resume and LinkedIn…

Vincent Le Moign, CC BY 4.0 <>, via Wikimedia Commons
Vincent Le Moign, CC BY 4.0 <>, via Wikimedia Commons

“Down the DDD rabbit hole I go”¹ wrote a colleague of mine in a PR². This made me wonder how a technique that was invented to make things easy, makes an experienced software developer feel lost. Let’s explore the Domain Driven Design together and see if we can make you feel a bit at home in the rabbit hole.

Imagine you’re part of a development team, working on an application that solves a particular business problem. The code is nicely structured and you can easily find the piece of code you have to change once you know what is asked…

Radek Kowalski

Solutions architect at KrampHub. Domain driven design and event storming enthusiast. Believer in independence, asynchronicity and eventual consistency.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store