Many have suggested using DDD to help define the functional scope of microservices. But how to apply this idea in practice is not clear to everyone. This talk will cover basic DDD concepts, and we'll discuss why and how DDD can help to create microservices with better autonomy, scalability, and reliability. Using examples, we'll navigate from a domain model to the design of both synchronous (REST-based) and asynchronous (reactive) microservices.

Target Audience: Architects, Developers, PM's, QA
Prerequisites: Understanding of Microservices and DDD is useful
Level: Advanced

Extended Abstract:
Many have suggested that DDD modeling techniques can help define the functional scope of microservices. But how to apply this idea *in practice* is not clear to everyone. DDD is NOT an approach to microservice design. However, DDD can help with some aspects of microservice design. DDD has had a resurgence with the advent of Microservices, specifically as it can help you design the right-sized microservices modeled around the domain.

This talk will examine how to take the results of domain modeling (specifically Domain-Driven Design) and map them to a microservices implementation for systems with better availability, scalability, reliability, and modifiability. This will include examples for the design of both synchronous (REST-based) and asynchronous (reactive) microservices. I will also explore various microservice design scenarios around DDD concepts such as aggregates (with entities and value objects), bounded contexts, domain events, anti-corruption layer, and various strategies for Bounded Context interactions.

Misunderstandings between developers and the business are a plague. Bad communication makes projects fail. This talk presents a remedy (including a practical demonstration with auditorium participation).

Domain Storytelling is a technique to transform domain knowledge into effective business software. It brings together domain experts and development teams.

We let domain experts tell us stories about their tasks. While listening, we record the stories using an easy-to-understand pictographic language.

Target Audience: Everyone involved or interested in software development, including non-technical people
Prerequisites: Curiosity
Level: Basic

Extended Abstract:
Misunderstandings between developers and the business are a plague. Bad communication makes projects fail. This talk presents a remedy (including a practical demonstration with auditorium participation).

Domain Storytelling is a technique to transform domain knowledge into effective business software. It brings together domain experts and development teams to: (a) understand the domain of a software system, (b) find microservices boundaries, and (c) talk about requirements.

We let domain experts tell us stories about their tasks. While listening, we record the stories using an easy-to-understand pictographic language.

The domain experts can see immediately whether we understand their story correctly. After very few stories, we are able to talk about the people, processes, and events in that domain.

The talk is aimed at everyone involved or interested in software development, including non-technical people.

In large organizations, creating value through IT often involves multiple teams, domains and systems. Join this talk to hear experience reports from a large Nordic Bank, about how domain-driven architecture can help tackle sociotechnical complexity at different scales. Concepts such as coherence, correspondence, recommoning and boundary-driven architecture will be contextualized with examples. The talk will also share a personal story of evolving the architect role from being a “maker” of good solutions to a “multiplier” of good conditions.

Target Audience: Architects, Developers, Product Owners, Agile Coaches, Decision Makers at all levels
Prerequisites: Understanding of agile, architecture, domain-driven design
Level: Expert

Extended Abstract:
At Danske Bank, we’re dealing with cross-team, cross-domain, cross-system change initiatives. It’s a complex sociotechnical environment, and we need large-scale structures to understand the big picture.

How can we scale these models to give direction and set boundaries, while leaving room for local design autonomy? How can we disseminate multiple models at multiple scales? How do we keep them supple enough to bend at places that need bending? And how can we help teams navigate the mess between the strategy floor and the engine room?

We made a lot of headway bringing strategy closer to the engine room. But not everyone of every team can be part of ideation, strategy, and design. Many developers who write customer-facing production code will not receive the “why” firsthand.

We set up collaborative experiments to facilitate decision understanding, decision feedback, and decision re-making. We probed architectural models at scale with minimal conceptual contours, capable of being fleshed out by decentralized design decisions. To deal with constant change, we looked for opportunities to refactor at the architectural level.

The talk will share field examples of practising domain-driven architecture. It illustrates how domain-driven architecture can be cross-pollinated by inspirations from product management, UX design, complexity, and organization theories.

It’s a call to action for architects and systems thinkers to become acute listeners of languages in contexts and deliberate feedback loop designers, to interact with complexity for sensing and understanding, to play with safe-to-fail experiments, and to embrace the learning and growth that only happens outside our comfort zone.

Event Storming ist eine Methode aus dem Domain-Driven Design, die es ermöglicht, sich gemeinsam die Fachlichkeit einer Anwendung zu erarbeiten. Richtig angewendet und bis zum Ende durchgeführt, bietet Event Storming aber noch mehr. Das Ergebnis kann nämlich sehr gut verwendet werden, um darauf basierend Bounded Contexts zu identifizieren.

Diese zeichnet dabei aus, dass wenig Kommunikation über Kontext-Grenzen hinweg passiert und das diese Kommunikation robust ist.

Zielpublikum: Architekt:innen, Entwickler:innen, Projektleiter:innen, Entscheider:innen, Product Owner
Voraussetzungen: Projekterfahrung
Schwierigkeitsgrad: Anfänger

Extended Abstract:
Event Storming ist eine Methode aus dem Domain-Driven Design, die es ermöglicht, sich gemeinsam die Fachlichkeit einer Anwendung zu erarbeiten. Richtig angewendet und bis zum Ende durchgeführt, bietet Event Storming aber noch mehr. Das Ergebnis kann nämlich sehr gut verwendet werden, um darauf basierend Bounded Contexte zu identifizieren.

Diese zeichnet dabei aus, dass wenig Kommunikation über Kontext-Grenzen hinweg passiert und das diese Kommunikation insbesondere robust ist.

In der Session stellen wir die Methode Event Storming vor und zeigen, wie man über die Methode Bounded Contexts ermitteln und diese so gestalten kann, dass sie lose gekoppelt sind, so dass es auch nicht problematisch ist, wenn ein Service temporär ausfällt.