Conference Report #

KanDDDinsky 2022 took place in Berlin from October 31 to November 2, bringing together practitioners working at the intersection of Domain-Driven Design (DDD), sociotechnical systems, and modern software architecture. It was my first time attending the conference, and it turned out to be less about isolated technical patterns and more about how organizations, teams, and software systems evolve together.

DDD was clearly the foundation, but the scope reached far beyond modeling and bounded contexts. The recurring theme was that software design is inseparable from organizational design, and that meaningful change requires understanding both.

General impression #

What stood out most was the shift in perspective: DDD is no longer primarily a modeling discipline for code, but a lens to understand and shape organizations.

Across talks and hallway discussions, three ideas kept reappearing:

• Software systems are sociotechnical systems
• Team structures shape architecture as much as architecture shapes teams
• Sustainable change depends on feedback loops between business and engineering

This makes KanDDDinsky feel like a conference about systems thinking applied to software organizations, rather than just architecture patterns.

Key themes across the conference #

Sociotechnical systems and team structures #

A dominant theme was the alignment between software architecture and team topology. Concepts from Team Topologies were frequently referenced, especially around:

• Stream-aligned teams
• Platform teams as enablers
• Reducing cognitive load through clear boundaries

The key insight: team structure is not a consequence of architecture—it is part of it.

Strategic DDD and bounded contexts #

DDD was discussed in a broader strategic sense rather than just tactical modeling. Discussions often centered around:

• Identifying subdomains and bounded contexts
• Understanding domain language evolution
• Avoiding premature abstraction in modeling

A recurring reminder was that models are hypotheses, not truths.

Systems thinking #

Many talks emphasized systems thinking as a necessary skill for software architecture. Instead of optimizing components in isolation, the focus shifts to:

• Feedback loops
• Emergent behavior
• Organizational constraints shaping technical outcomes

The message was clear: local optimization rarely leads to global improvement.

Event-driven architecture and complexity management #

Event-driven systems were discussed not as a trend, but as a way to manage complexity—if done carefully.

Topics included:

• Event sourcing as temporal modeling
• Managing workflows through events
• Avoiding uncontrolled coupling in distributed systems

A key takeaway: event-driven systems do not reduce complexity by default—they redistribute it.

Selected talk highlights #

Design and Reality – Mathias Verraes #

This opening keynote emphasized closing the gap between design assumptions and real-world behavior. Instead of treating design as a static phase, it should be an ongoing interaction with reality.

A strong message was to include real feedback earlier and more often in system design.

Architecture for Flow – Susanne Kaiser #

This talk combined Wardley Mapping, DDD, and Team Topologies to reason about flow in sociotechnical systems.

The main idea was to connect strategic planning with technical architecture, making evolution paths more explicit and navigable.

Systems Thinking – Michael Plöd #

A practical combination of Team Topologies and context mapping was presented to understand system interactions.

The focus was on improving conversations between teams rather than optimizing diagrams.

Thriving in Complexity – Trond Hjorteland #

A reminder that software systems operate in inherently complex environments. Rather than simplifying reality too aggressively, we should design for adaptation.

Complexity was not treated as a problem to eliminate, but as a condition to work with.

Road-movie Architectures – Uwe Friedrichsen #

A strong critique of “final architecture states”. Architecture is not a destination but a continuous journey.

Important ideas included:

• Designing for change over time
• Planning for decommissioning early
• Treating simplicity as an ongoing effort, not an initial achievement

Start with DDD when you have a monolith – Javiera Laso #

A pragmatic look at applying DDD in legacy systems. The key message was to understand the domain deeply before attempting decomposition.

DDD was framed as a discovery tool rather than a restructuring strategy.

How to relate OKRs to technical real estate – Marijn Huizendveld #

This talk connected strategic business goals with architecture decisions using mapping techniques.

It helped make trade-offs more visible and explicit across business and engineering.

Balancing Coupling in Software Design – Vladik Khononov #

Coupling was reframed as unavoidable and even necessary. The goal is not to eliminate it, but to understand and manage it.

Key dimensions included:

• Distance
• Strength
• Time

A useful takeaway: coupling defines the degrees of freedom in a system.

Culture – The Ultimate Context – Avraham Poupko #

A powerful closing keynote emphasizing that culture is the ultimate system context.

Technical systems and organizational structures only function within the boundaries of shared meaning, language, and trust.

Personal reflection #

What made KanDDDinsky 2022 special was the consistent bridging of disciplines: software architecture, organizational design, and business strategy were not treated separately.

Instead, the conference reinforced a more integrated view:

• Architecture is organizational design expressed through software
• DDD is a tool for shared understanding, not just modeling
• Sustainable change requires continuous alignment between teams and systems

It felt less like attending a set of talks and more like participating in a shared conversation about how modern software organizations evolve.

Closing note #

KanDDDinsky 2022 was my first exposure to this conference, and it left a strong impression. The combination of deep technical thinking with organizational and cultural perspectives made it particularly valuable.

I will likely revisit many of the ideas from these talks in future work—especially those around system boundaries, team structures, and the continuous nature of architecture.