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.

Ward Cunningham's original technical debt metaphor in 1992 was not about bad code. Debt could be a business and learning strategy: we build with the understanding we have today, use the software, learn something new, and discover that yesterday's good design no longer fits what we now know.

More recently, Kent Beck has reframed a similar tension as Features vs. Future: delivering value now while preserving our ability to respond to what comes next.

AI-accelerated code production makes that learning debt more urgent.

This talk explores why faster execution loops, better DDD-informed specifications, disciplined TDD, and stronger AI harnesses are only part of the answer. The deepest learning debt is social and non-linear. It accumulates in our pursuit to understand the problem, notice assumptions, let our mental models shift, decide what matters, take ownership, and act under uncertainty.

Drawing on Domain-Driven Design, collaborative modeling, cognitive science, and dialogical practices, we'll explore how we can make thinking together a deliberate part of software design.

Borrowing Kari Zeller's language, how might we* re-place ourselves* as AI changes how software gets made? Instead of simply inserting AI into our existing processes and ways of thinking, what would it mean to rethink how we work with each other and with AI, where we create value, and what we take responsibility for?

Key Takeaways

• Technical debt is also a learning story. Revisit technical debt through single- and double-loop learning, and explore what changes when AI accelerates the execution loop.
• Thinking together is part of software design. Explore a cognitivescience-informed language and practical framework for noticing assumptions, opening perspectives, and learning together.
• Re-place ourselves and take leadership. Explore leadership as a distributed capacity available to all of us: the capacity to step forward when certainty has not arrived, rethink where we create value, and reclaim our agency and accountability as the ground keeps shifting.

Who Is It For?

• Anyone who shapes software: developers, architects, tech leads, product, UX, and business.
• Anyone experimenting with AI-assisted development and wondering what these changes mean not only for how we work, but for who we are as software professionals.
• Anyone who has seen technically successful teams struggle with shared understanding, ownership, or the ability to change direction together.

Level

Practitioner to advanced