In this highly interactive masterclass, you will learn to use Domain-Driven Design not only as a modeling approach, but to facilitate collaboration, structure architecture decisions, and lead strategic software design.

Complex software becomes difficult to evolve when knowledge is fragmented, boundaries and responsibilities are unclear, and decisions span systems, teams, and organizational interests.

AI raises the stakes. As generating software becomes faster and cheaper, maintaining shared understanding of what we are building, why, and how it fits together becomes harder.

As code becomes cheap, continuous comprehension becomes expensive.

Over two days, you will practice DDD as a sociotechnical design and leadership practice for building shared understanding, making strategic choices, and growing ownership.

We focus on two complementary capabilities:

• Domain-Driven Thinking — collaboratively understanding and modeling complex domains
• Strategic & Architecture Thinking — turning that understanding into boundaries, priorities, dependencies, and architecture decisions

Who This Is For

Software professionals working across complex domains, systems, and organizational boundaries:

• Engineers and architects
• Product leaders
• Domain experts
• Agile coaches
• UX professionals

Especially valuable when complexity is outpacing shared understanding, ownership is unclear, or architecture decisions require alignment across teams.

What You'll Walk Away With

You will develop your capacity to:

• Facilitate conversations that turn different perspectives into shared domain understanding
• Structure architecture decisions around value, boundaries, dependencies, and trade-offs
• Lead strategic software design by creating clarity and engaging others across teams, with or without a formal leadership role
• Apply strategic DDD practices to real organizational and architecture challenges

Day 1 — Domain-Driven Thinking

Build shared understanding of a complex domain through hands-on collaborative modeling:

• Get started with a lightweight DDD Starter Modeling Process
• Build the big picture quickly with EventStorming
• Discover subsystem boundaries and behavior through Collaborative Modeling
• Ask better modeling questions and use authentic conversations to uncover deeper domain insight and emerge a Ubiquitous Language
• Express business complexity through domain abstractions and models

Day 2 — Strategic & Architecture Thinking

Lead strategic design conversations and structure architecture decisions using DDD:

• Business Model Canvas: quickly grasp the business context your software serves
• Core Domain Strategy: focus attention where software creates strategic value
• Context Mapping: reason about how systems and teams decouple, connect, and collaborate
• Domain Message Flow: validate critical business scenarios across system boundaries
• Bounded Context Design Canvas: collaboratively design and refine system boundaries
• Explore how DDD can help us stay strategic and in the driver's seat in AI-pervasive work

Both days combine analog modeling with structured conversations and hands-on learning. You'll leave with a coherent approach you can bring directly into your own design and architecture conversations.

Prerequisites

Experience working with software in teams and curiosity about what the future of software development asks of us.

AI can generate features fast. It cannot generate shared understanding, or the ownership that comes from thinking and caring together.

Every piece of code carries traces of the conversations that were had or skipped, the compromises made under pressure, the misunderstandings no one named out loud. Read a system long enough and you’re not just reading architecture. You’re reading the organization, its power dynamics, and the quality of its collaboration.

That’s social debt. And unlike technical debt, there’s no git revert.

Key Takeaways

1. Code is a fossil record of our conversations. How do we architect the conversations themselves?
2. Social, cognitive, and emotional debt compound under AI acceleration. How do we name what nobody wants to say out loud?
3. Architecture is a sociotechnical seesaw. When AI tips the scales, how do we keep our balance?

Who Is This For?

• Anyone who shapes software: developers, architects, tech leads, product, UX, business
• Anyone who has sat through a “collaborative” session and felt something was missing
• Anyone asking what great collaboration looks like when AI is part of the team

Level

Practitioner to advanced

Format

Slides

Full description

In complex teamwork, where no one person holds the full picture, the quality of collaboration is a real architectural concern. When design processes collapse into individual decisions made in isolation, or into workshops that look collaborative but lack genuine diversity of perspective, the debt is baked into the system before a line of code is written.

That’s social debt, accruing interest.

Now add AI. Code generation accelerates. The conversations that should be happening get squeezed out by the pressure to ship. Cognitive debt compounds social debt when output outpaces shared understanding, when systems grow faster than our collective ability to explain them.

This is not an argument against AI. It is an argument for honesty about the full cost. The uncomfortable question is whether we are scaling output or scaling misalignment. In the rush to celebrate productivity, are we paying a price in human cohesion, craft, and the joy of building something together?

Drawing on research and practical experience with clients, this session explores sociotechnical architecture beyond Inverse Conway: what it takes to keep your balance on the sociotechnical seesaw when AI tips the scales. We’ll look at social, cognitive, and emotional debt not as inevitable costs of progress, but as signals pointing toward better ways of navigating complexity together.