Most introductions to DDD start with bounded contexts. Ours starts by asking whether DDD is aimed at a problem you actually have, and gives you twenty minutes to find out. What would your step three be?

Virtual Domain-Driven Design@virtualddd.com · 8h ago

Our new DDD starting point is an EventStorming timeline, so it ends in two empty stickies. Step three and beyond are not written yet, because we need to design that together. buff.ly/0btwtGn

Broken things at work keep breaking, and we rarely have the language for why. @trond.hjorteland.com introduces Open Systems Theory, then we diagnose real dysfunctions live, together. Get info & RSVP: buff.ly/H580ohp

Organisational Dysfunctions and Open Systems Theory

Most teams can list what is broken at work but lack a language for why it keeps recurring. Trond Hjorteland diagnoses real dysfunctions using Open Systems…

virtualddd.com

There's a tension in every design session I facilitate that I don't think can be resolved, only held. >(A thread)<

Four "services" drawn as separate boxes, but one tangled codebase underneath, in a medical product nobody could safely change. @vanessaformicola.bsky.social shared how naming what a team actually owns… Read, watch, or listen: buff.ly/5JB3t8z

Social Decision Records: The Other Half of Architecture

Social decision records apply ADR rigour to people decisions. Learn how Vanessa Formicola built team ownership before refactoring four tangled services.

buff.ly

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.

AI is useful. Handing your thinking over to it is a different thing entirely. There is a name for that, and our community should recognise it immediately. Cognitive offloading is the act of giving the mental work to the tool. >>>

Virtual Domain-Driven Design@virtualddd.com · 6d ago

AI drafts, suggests and helps us build. What it does not do is decide what we think. The thinking, the opinions and the mistakes are ours. buff.ly/0voDv53

AI drafts, suggests and helps us build. What it does not do is decide what we think. The thinking, the opinions and the mistakes are ours. buff.ly/0voDv53

AI usage on this site — Virtual DDD

Where AI is used on this site and where it is not: the recordings, the writing, the images, and the site itself.

buff.ly

When the network vanishes, most systems just stop working. One week out: Emilio Carrión joins us to talk offline-first architecture and surviving a national blackout. Register: virtualddd.com/sessions/sur...

Virtual DDD is where I've worked out most of what I think about software design, in public, usually with someone disagreeing with me. For anyone who can't get to conferences and meetups, or would rather not. The new site is that community catching up with itself.

Virtual Domain-Driven Design@virtualddd.com · last wk.

People are reaching for DDD again, twenty-odd years after Evans wrote it down. So are we, after a fashion. virtualddd.com has been rebuilt from the ground up, and the timing isn't entirely a coincidence.

People are reaching for DDD again, twenty-odd years after Evans wrote it down. So are we, after a fashion. virtualddd.com has been rebuilt from the ground up, and the timing isn't entirely a coincidence.

There's a pattern that turns up in almost every struggling team. The problem gets named as a technical one, the technical fix gets applied, and nothing actually improves. Listen, watch or read about @mathiasverraes.bsky.social and many more of our @dddeu.bsky.social special stories! buff.ly/lWZiNoX

We design for high availability assuming the cloud is always reachable. What happens when a nationwide blackout cuts warehouses off completely? Emilio Carrión shares how Mercadona Online kept fulfilling orders anyway. Get info & RSVP: virtualddd.com/sessions/sur...

Architects often start enthusiastic and end up worn down by the gap between vision and what systems allow. Larisa Feldman spent years watching this happen before reluctantly stepping into the role herself. Read, watch, or listen: buff.ly/wg1Inqg

The Reluctant Architect: A Career Path Nobody Plans

Larisa Feldman spent years watching architects lose their spark—then became a reluctant architect herself. On why good architecture serves engineers.

buff.ly

Two weeks ago at @dddeu.bsky.social, the three of us behind the @virtualddd.com SFSAD finally met in person. Andrea Magnorsky, Andrew Harmel Law and I have been recording these for almost a year, all of it remote, and DDD Europe was the first time we were actually in the same room together. >>>

Virtual Domain-Driven Design@virtualddd.com · last mo.

It's hard when teams identify problems as technical, but the real issues are deeper. We interviewed nine practicioners at @dddeu.bsky.social and ask them: what's the hardest part of facilitating software architecture and design? Read, watch, or listen: buff.ly/urFrFzD

We prepare for a design session like any other meeting. Agenda, right people, a technique we trust. Then it underdelivers, and we go looking for what went wrong with the room. >>>

5-step checklist to debias design choices. "Debiasing Design Decisions" - @kenny.weave-it.org & @evelynvankelle.bsky.social . Watch: youtu.be/rcLRzDm8cwQ #amaberlin

Debiasing Your Software Design Decision-Making – Kenny (Baas) Schwegler & Evelyn van Kelle

YouTube video by Agile meets Architecture

youtu.be

It's tough when clients already have "the answer" before understanding the problem. Kim Kao shared how he redirected a client focused on Kubernetes to map their business impact first. Read, watch, or listen: virtualddd.com/facilitating...

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. >>>

As an anthropologist, I endorse this message!

When methods fail due to cultural resistance, not technique. @heimeshoff.bsky.social shares his story where feedback felt like violence & leadership gave a quiet "no." Read, watch, or listen: buff.ly/1ANfd4z

Cultural Resistance to Collaborative Modeling

Why EventStorming and collaborative modeling fail against cultural resistance — and why a real mandate matters more than the right method.

buff.ly

If someone brings up an alternative and you're like oh no, that's a horrible idea think about okay what assumptions may this person be making that are not being clarified. Listen, Read or Watch to @noctovis.bsky.social explaining how this and more can make for better conversations: buff.ly/F8qaXIw

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 >>>

Skipped a week, sorry non-Dutch friends! But this week's newsletter is translated again! www.felienne.nl/2026-14/#eng... (Including a translation of my opening remarks in The Dutch Parliament this week on AI in schools)

AI in week 14

In de Tweede Kamer, een gebrek aan vibe coding en heel veel podcasts!

felienne.nl

When we apply tactical DDD patterns, we do it for a reason. We want our code to follow along with how our understanding of the domain evolves. Eric Evans calls it refactoring toward deeper insight. And we deliberately spend more effort on core domains, because >>>

We can do that by modelling collaboratively. Collaborative modelling is becoming more important as we figure out how to use AI. Join me and @kenny.weave-it.org in our workshop, where we will help you improve the quality of your collaborative modelling. www.avanscoperta.it/en/training/... [2/2]

Collaborative Software Design Workshop

Based on the book Collaborative Software Design, we provide you with the facilitation skills needed to guide a group and lead impactful modeling sessions.

avanscoperta.it

If you feel like AI is making you write code faster, how do you know for sure? METR ran what is probably the most rigorous independent study to date. A proper randomised controlled trial with experienced open-source developers. >>>

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. >>>

Engineers sometimes see architecture as bureaucratic overhead with no real value. And they might have a point. Most architects got where they are because something worked for them in a specific context. Past success creates anchoring bias. >>>

It's hard when method wars obscure the actual challenge. @swardley.bsky.social shared how mapping a system first avoids this trap & leads to success. Read, watch, or listen: buff.ly/kzK76iV

Why Method Wars Hide the Real Architecture Problem

Simon Wardley shares how mapping component evolution resolved methodology wars on HS2. Discover why understanding context matters more than choosing the right method.

buff.ly