Subdomain, bounded context, service. Three boundaries, drawn by different people, for different reasons. The pain is rarely picking the wrong one. It is picking one and assuming the other two came for free.

That tension is also why I was grateful to be pulled onto a panel by Fancy Karolina Tóth on mental health with @marianhartman.bsky.social and @jpelrine.bsky.social, talking about how collaborative software design, sociotechnical systems and decision-making affect how we actually feel at work. >>>

We asked the audience in one of our talks how much their organisation prioritises coaching, training and mentoring. 27 people answered. The average was 3.8 out of 10. Small sample, probably biased by the room. But it matches what I keep seeing elsewhere. >>>

Almost no one is checking the outcomes: what that output actually does, how it changes the team socially, and whether anyone is still teaching people and hardening their engineering disciplines. >>>

And the place we keep landing is the same one too: we should be focusing on understanding our customers and our domain. The deep work. The things domain-driven design has been pointing at for over 25 years. >>>

Last week I was invited to Craft Conf to give two talks with Evelyn van Kelle. Fourteen years ago the conversation was about lines of code and SonarQube KPIs. This time it was token maxing and doing half the work with AI. Same song, different instruments. >>>

At @dddeu.bsky.social this year, Krisztina Hirth, @maxsc.bsky.social, @hschwentner.bsky.social and I are running a hands-on session where groups each tackle distributed systems integration using a different collaborative modelling approach >>>

I recently asked a room of practitioners: "How much are you involved in architectural decision making?" The average was 7 out of 10. Sounds good right? Then I asked the same group: "What is software architecture?" >>>

The biggest blocker to teams making intentional software architecture decisions isn't technical complexity. It's not knowing whether they're allowed to decide. Last week at AI Native Amsterdam I talked about facilitating software architecture while AI agents write the code. >>>

The speed at which AI agents write code is no longer the bottleneck. Whether we understand what that code is actually doing, that's where it gets interesting. On 7 April I'll be speaking at the AI Native Netherlands meetup at the Miro offices in Amsterdam. >>>

Everyone is talking about how AI will change the way we build software. Almost nobody is talking about what was already broken before it arrived. >>>

As per usual practice, we are finalising our slides on the train, one day before @amaconf.bsky.social kicks off in Berlin. The talk is about debiasing your software design decisions and the structured interventions you can take to counter them. ...

Here's something worth sitting with: a product owner deciding "the user should never have to re-enter this information" is making an architecture decision. A domain expert saying "that data doesn't belong here" is making an architecture decision. They just don't always call it that. ...

First day of another DDD foundation workshop, and we hit the wall that almost every team hits: naming. Not "what should we call this?" — that's the surface question. The deeper one is: how much does a name already decide for you? ...

Came across this take recently: "How long until the DDD community realises AI/LLM assisted programming is still DDD, but you no longer need to do the actual implementation, just document & validate it?" We already do. The bounded context pattern is still very much valid. ...

After 2 years consulting DHL eCommerce BeNeLux, I've decided to join them as software architecture enabler. The reason? I'm simply not done yet. And I wonder if I ever will be. ...

We started day 2 of the Tactical DDD training this morning, not with coding, but with discovering and formalising acceptance criteria through Example Mapping. These acceptance criteria then become input for domain modelling with responsibility-driven design through CRC-card modelling. ...

I usually kick off my tactical DDD training with this flipchart exercise, because there's a misconception I run into time and again: people confusing monoliths with big balls of mud. ...

@evelynvankelle.bsky.social and I are speaking at @amaconf.bsky.social 2026, and we've been sitting with a question that keeps coming up in our consulting work: when a design choice just feels right, how do you know whether that's genuine insight or a cognitive bias in disguise? ...

A friendly reminder that developers using agentic AI just add an abstraction onto this. At least a developer writing their own code still roughly understands the model they're writing. With Agentic AI, they don't and critically engaging with the model dilutes even more, and the model drifts more

Many Product Owners view software architecture as a technical concern, something strictly for the developers. Yet, the boundaries of a software system are often defined by business decisions and language, not just code. ...

There is a persistent friction in design sessions where facilitators conflate equal speaking time with equal contribution. The goal of collaborative modelling isn’t to ensure everyone speaks the same amount; it is to ensure that everyone’s knowledge is effectively placed on the table. ...

During a training session with tech leaders today, a familiar friction point regarding architecture decision-making surfaced. Participants consistently observed that architects operating outside the teams are perceived as controlling and micromanaging. This behaviour often stems from a paradox. ...

The name you give a Bounded Context isn't just a label—it's the critical foundation that frames your entire DDD modelling conversation. Day 1 of my Domain-Driven Design training was dedicated to EventStorming and distilling Bounded Contexts using Context Mapping....

What if you could ditch the prepared slides and adapt your talk to the audience in real time? That's what I got to experiment with yesterday at the Frontify software talks meetup in St. Gallen. My talk was about technical leadership and facilitating better architectural decision-making. Instead ->

I'm looking forward to speaking at the Software Talks meetup at Frontify in St Gallen near Zurich this Thursday. Being back in Switzerland is always a pleasure and I will be talking about Technical Leadership for Architectural Decision Making. Too often, architectural discussions turn -->

Back in a training session today with @evelynvankelle.bsky.social, talking about the book @gienverschatse.com, she, and I co-authored. Today was all about what surfaces when we tackle software design and architecture challenges. A big part of that is resistance. If we want to make sustainable -->

It's strange to think that patriarchal norms can affect the way we build software, but they do. I'm happy to share that the article my wife, Vanessa, and I wrote has been published in the @nljug.bsky.social Java magazine. It was our first time writing an article together, and it was...

So, imagine this: one complex design problem, four different collaborative modeling tools, four facilitators, and 45 minutes to solve it with a group of 8! That was the intense setup Krisztina, ‪@maxsc.bsky.social‬, ‪@hschwentner.bsky.social‬, and I ran at the DDD Europe hands-on labs.