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.

Mehr Inhalte dieses Speakers? Kein Problem, schaut doch mal bei sigs.de vorbei: https://www.sigs.de/autor/henning.schwentner

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.

To understand and impact a large-scale environment (a team, an enterprise, a society), we need effective modeling. Over the years Domain-Driven Design (DDD) has gained a visible foothold in software-centric corporate change agendas.

In my work as a DDD evangelist and sociotechnical architect in large organizations, I’ve lived and breathed DDD to decouple domains and systems, to kickoff greenfield initiatives, to deploy brownfield modernization, and to design reteaming using the Inverse Conway Maneuvre and Team Topologies.

All that hard work has brought me many a pat on the shoulder. But time after time I’ve been surprised by how I/we could make things worse by attempting to make things better. I’ve been frustrated to witness bubbly energy and DDD enthusiasm from event storming workshops and alike evaporate like a deflated balloon. Improvements remained temporary and local. New practices failed to gain widespread adoption. I have to admit with absolute candor that it is so very hard to make lasting impact with DDD, or whatever else technology or tooling du jour.

In this talk, I will share my observations through the systems thinking lens, of what happened in a large change initiative in a big bank, where DDD played a central role. You will hear examples of sociotechnical systems dynamics and episodes about shifting dominance of competing feedback loops. You will be invited to partake in a postmortem forensic of what could have happened, what unfortunately didn’t happen, and the many what-if’s of alternate realities, or pasts. For people new to systems thinking, a positive side benefit can be a sneak peak into systems modeling building blocks and systems archetypes.

As a community, we’ve come a long way modeling software-centric systems, thanks to practice like DDD, architecture and Team Topologies. But what about the runtime dynamics of large human systems in our working environment, especially when such systems are full of fixes that don’t work? As software professionals, can we just tell jokes about SAFe, about policy makers in our company who can copy the Spotify Model, but not paste it? Or should we give the usual shrug – “it’s the system’s fault”?

From a systems standpoint, we are part of the same mess. If we can become better at seeing and naming the elephants in the room, not as random events, but as systemic patterns described through a consistent systems language, then the current messy reality is no longer our enemy but our ally. It can become a generative force for us to identify leverage and sustain influence in large organizational spaces.

I hope this talk will spark interest in system dynamics modeling. It is a call to action for boundary spanners and design-oriented change agents to explore abstractions, heuristics, modeling and visualization techniques to articulate and reason about dynamic system behavior.

How can we architect shared experiences to surface mental models so they can be challenged, improved and no longer stand in the way of change? With the rising initiative fatigue in large enterprises, how do we collectively discover leverage points, design and deploy systemic interventions with long lasting impacts?

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

Good design of software systems, much like good product design, requires immersive knowledge of the problem space. And yet we often optimize solution architecture primarily for execution, making crucial decisions about structure and technology upfront, when we still know little about the problems they are supposed to solve.
This talk will present an alternative: An incremental, evolutionary approach to building complex systems, grown holistically from the inside out, starting with the business, and optimized for fast feedback and learning.

Target Audience: Architects, Developers, Heads of IT
Prerequisites: Knowledge of design patterns and DDD basics recommended
Level: Advanced

Extended Abstract:
When we design systems from scratch, especially complex distributed systems, we tend to make far reaching decisions at a very early stage – at a time, when we have the least knowledge about the underlying business problem. But some issues are impossible to solve just by assumption, and even with great experience, it's quite common to get the first design at least partially wrong.
Unfortunately, the first design is also often the one that ends up being implemented.
On a technical level, this has immediate consequences: If we assume boundaries in the wrong place, or forget or omit important aspects of communication, we can end up with brittle services, performance issues, and needlessly coupled modules and components, which are painful to maintain and deploy.
On an organisational level, misplaced boundaries and unfortunate design decisions often lead to entire team structures and workflows in all the wrong places, thus creating immense communication overhead, or worse: active prevention of learning and improvement for the rest of the project lifetime.
One way to mitigate the impact of those decisions, and to verify our initial assumptions, is to start implementation not with a complete solution architecture in mind, but rather with the smallest possible footprint: A plain, but fully operational prototype of the domain model, which we can stress, observe, and explore – and change easily, if we run into problems. This way, we can actually _see_ our design work, and gain valuable insights.
As a side-effect, we can also deliver customer value much earlier, by using the raw domain model to power UX/UI prototypes – replacing fakes and click-dummies with a working application.
As a team, we can learn and improve together, making important decisions when they are needed, adding layer by layer of additional (technical) complexity in small, incremental steps, until we are truly ready to scale out.
By combining UX prototyping, Domain Driven Design, and making use of the fractal nature of large-scale systems, we can highlight difficult or problematic choices early, improve fundamental architecture decisions with low risk, and ultimately develop not only to better solutions, but also to a better and more sustainable software development process.