Konferenzprogramm

Die im Konferenzprogramm der OOP 2024 angegebenen Uhrzeiten entsprechen der Central European Time (CET).

Track: Domain-Driven Design expands our horizons

Nach Tracks filtern
Nach Themen filtern
Alle ausklappen
  • Mittwoch
    31.01.
  • Donnerstag
    01.02.
, (Mittwoch, 31.Januar 2024)
09:00 - 10:30
Mi 8.1
Domain-driven Design: Konzepte und Fallstricke
Domain-driven Design: Konzepte und Fallstricke

Domain-driven Design (DDD) steht für eine Vielzahl an Techniken wie strategisches DDD, taktisches DDD und kollaborative Modellierung. Dieser Vortrag gibt einen Überblick über das DDD-Universum. Dabei stellt er nicht nur die verschiedenen Konzept vor. Er zeigt außerdem auch die jeweiligen Vor- und Nachteile der Praktiken auf und weist auf die typischen Fallstricke hin - und wie man sie vermeiden kann.

Zielpublikum: an Software-Architektur Interessierte
Voraussetzungen: Grundlegendes Verständnis von DDD
Schwierigkeitsgrad: Anfänger

Mehr Inhalte dieses Speakers? Schaut doch mal bei sigs.de vorbei: https://www.sigs.de/autor/eberhard.wolff

Eberhard Wolff ist Head of Architecture bei SWAGLab und arbeitet seit mehr als zwanzig Jahren als Architekt und Berater, oft an der Schnittstelle zwischen Geschäft und Technologie. Er ist Autor zahlreicher Artikel und Bücher, trägt regelmäßig als Sprecher auf internationalen Konferenzen vor und streamt wöchentlich zum Thema Software-Architektur. Sein technologischer Schwerpunkt sind moderne Architektur- und Entwicklungsansätze wie Cloud, Domain-Driven Design und Microservices.

Mehr Inhalte dieses Speakers? Schaut doch mal bei sigs.de vorbei: https://www.sigs.de/autor/eberhard.wolff

Eberhard Wolff
Raum 01
Eberhard Wolff
Raum 01

Vortrag Teilen

11:00 - 11:45
Mi 8.2
Domain Patterns – wie die Domäne sich auf die Architektur auswirkt
Domain Patterns – wie die Domäne sich auf die Architektur auswirkt

Beim Analysieren und Zerlegen von Legacy-Systemen nach DDD sind wir auf Domänen gestoßen, die einfach in Subdomänen aufgeteilt werden konnten, und auf Domänen, bei denen es deutlich schwieriger war. Auch das Alter und der Entwicklungsgrad einer Domäne haben Einfluss auf unsere Möglichkeiten, gute Subdomänen zu finden und die Legacy zu modularisieren. Inzwischen können wir diese Unterschiede beschreiben und haben verschiedene Domain Patterns gefunden und benannt. Ich freue mich auf Feedback und Diskussionen von den Zuhörer:innen.

Zielpublikum: Architekt:innen, Entwickler:innen, Business-Analyst:innen, Projektleiter:innen
Voraussetzungen: Projekterfahrung, Basiswissen in DDD
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
In den letzten Jahren haben wie eine Reihe von Domänen mit Subdomänen gesehen und mit DDD zerlegt. Ziel war natürlich immer, ein oder mehrere Softwaresysteme auf die Subdomänen aufzuteilen und eine sinnvolle Zerlegung des Softwaresystems anhand des Domänenschnitts zu erreichen. Mit der Zeit haben wir den folgenden Eindruck gewonnen:

  1. Es gibt (Sub-)Domänen, die sich leichter in (Sub-)Subdomänen zerlegen lassen, und solche, bei denen es deutlich schwerer ist.
  2. Es gibt Umsetzungen in fachliche Kontexte, die es leichter oder schwerer machen, das Legacy-System zu zerlegen.
  3. Die Entwicklung der Domäne und der Software beeinflussen sich gegenseitig und die Legacy-Software ist je nach Entwicklungszustand anders zu zerlegen.

In diesem Talk werde ich unsere Überlegungen zu Domain Patterns und ihrer Umsetzung vorstellen und hoffe auf Diskussionen und Feedback.

Mehr Inhalte dieses Speakers? Schaut doch mal bei sigs.de vorbei: https://www.sigs.de/autor/carola.lilienthal

Dr. Carola Lilienthal ist Software-Architektin und Geschäftsführerin bei der WPS – Workplace Solutions GmbH und entwickelt seit mehr als 10 Jahren mit ihren Teams Software-Architekturen nach den Prinzipien des Domain Driven Design. Sie ist Autorin des Buchs "Langlebige Softwarearchitekturen", hat das Buch "Domain-Driven Design Distilled" von Vaughn Vernon ins Deutsche übersetzt und 2023 ihr neues Buch "Domain-Driven Transformation" veröffentlicht.

Mehr Inhalte dieses Speakers? Schaut doch mal bei sigs.de vorbei: https://www.sigs.de/autor/carola.lilienthal

Carola Lilienthal
Raum 01
Carola Lilienthal
Raum 01

Vortrag Teilen

14:30 - 15:30
Mi 8.3
Navigating sociotechnical complexity with DDD and friends
Navigating sociotechnical complexity with DDD and friends

Xin has lived and breathed DDD for more than a decade. Drawing on her experiences, Xin makes a case for DDD’s rising relevance in a post-modern world, where aging companies struggle with aging software, while adding new software and complexity to their IT portfolio. With good attractor effect DDD is evolving from a software-centric design discipline to a multi-dimensional toolbox. Join Xin to reflect together on, how DDD can help us sustain meaning and productivity in a reality of vast sociotechnical complexity and constant change.

Target Audience: Software Professionals, Architects, Leaders, Agile Practitioners, Change Agents, Facilitators
Prerequisites: Basic DDD understanding; Prior DDD experience is not a must but helps understand the deeper message
Level: Advanced

Extended Abstract:
What is the first thing that comes to mind when you hear the word DDD – Domain-Driven Design? The geeky technical patterns (Value object, Entity, Aggregate, etc.)? Walls decorated with colorful event storming stickies? A miracle cure to rescue change initiatives in large companies? Or are you thinking of a software development method born in the pre-cloud and pre-microservice era, which after 20 years is still struggling to gain traction?
Xin has lived and breathed DDD for more than a decade. In this talk, Xin makes a case for DDD’s rising relevance in a post-modern world, where aging companies struggle with aging software, while adding new software and complexity to their IT portfolio. The reflections will be grounded in solid DDD experiences and observations from the battlefield. With good attractor effect DDD can evolve from a software-centric design discipline to a multi-dimensional toolbox of thinking, modeling and collaboration techniques. You will be invited to explore DDD's value proposition and reflect upon how to leverage DDD’s strategic and tactical design approaches in your own context.
Globally, there is an increasing interest in DDD. Hope is evergreen for DDD to become a key ingredient in the magic potion for tackling the increasing complexity, not only at the heart of software, but also at the heart of sociotechnical organizations. How can DDD help us create meaning and productivity in a reality of multi-dimensional complexity and constant change? What’s in it for me? What’s in it for us?

Xin Yao is a sociotechnical architect, DDD evangelist and independent consultant. She believes that a product, domain and team-oriented architecture is the super glue to bind multiple agile teams navigating toward a common horizon. She’s spearheaded large-scale change initiatives in boundary-spanning architect roles, weaving together strategy, products, teams, systems, domains into coherent models to guide progress and reduce stress. She architects collective experiences in scale-ups and enterprises to unravel complexity and discover leverage points. In sociotechnical environments where a team’s cognitive capacity is under constant stress, she practices domain-driven design and facilitates collaborative modeling to help teams and organizations make sense, make decisions and make intuitive business software.

Xin Yao
Raum 05
Xin Yao
Raum 05

Vortrag Teilen

17:00 - 18:00
Mi 8.4
Bounded Contexts mit Event Storming finden
Bounded Contexts mit Event Storming finden

Dass Event Storming eine Methode aus dem Domain-driven Design ist und man damit ein gemeinsames Verständnis der Fachlichkeit erreichen kann, ist vielen bekannt. Ich möchte in dieser Session darüber hinausgehen und euch zeigen, wie man Event Storming auch als eine Grundlage für einen guten Serviceschnitt nutzen kann.
In meinem Vortrag erläutere ich euch die Vorteile von Event Storming und verprobe die Methode anhand eines Praxisbeispiels. Das Ziel ist die Erstellung von Aggregaten, die die Basis für Bounded Contexts bilden.

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

Extended Abstract:
Beim Finden der Bounded Contexts gehe ich auch darauf ein, was bei deren Kommunikation untereinander beachtet werden muss und wie man die Kommunikation gestalten kann, um später unabhängige Services realisieren zu können.

Ina Einemann ist als Agile Coach bei der Open Knowledge GmbH in Oldenburg tätig. Ihr Tätigkeitsumfeld umfasst neben ihrer Arbeit als Scrum Master auch Aufgaben aus dem Bereich PO und Requirements Engineering. Sie beschäftigt sich mit agilen Methoden und Vorgehensmodellen und berät Teams bei der Umsetzung agiler Praktiken. Sie ist außerdem einer der Podcasts-Host.

Ina Einemann
Raum 11
Ina Einemann
Raum 11

Vortrag Teilen

, (Donnerstag, 01.Februar 2024)
09:00 - 10:30
Do 7.1
Loosely or lousily coupled? Understanding communication patterns in microservices architectures
Loosely or lousily coupled? Understanding communication patterns in microservices architectures

In a microservices architecture, services shall be as loosely coupled as possible. Still, they need to communicate with each other in order to fulfill business requirements. Now there are so many questions around this communication (synchronous vs asynchronous, event-driven? what is the influence on the coupling of your services? ...?). This talk will help you answer these questions for your project. You will better understand not only the architectural implications but also the effect on the productivity of your teams.

Target Audience: Architects, Engineers, Developers
Prerequisites: Basic experience with distributed systems
Level: Basic

Extended Abstract:
In a microservices architecture, services shall be as loosely coupled as possible. Still, they need to communicate with each other in order to fulfill business requirements. Now there are so many questions around this communication:

  1. What are the general possibilities to communicate? For example synchronous, asynchronous, or event-driven communication. What are the tradeoffs and which communication style should you prefer?
  2. What is the influence on the coupling of your services? For example, asynchronous communication reduces temporal coupling between services.
  3. What do I have to consider when selecting a certain communication style? For example, you need to apply certain resilience patterns if you want to use synchronous communication.

This talk will help you answer these questions for your project. You will better understand not only the architectural implications but also the effect on the productivity of your teams.

Mehr Inhalte dieses Speakers? Schaut doch mal bei sigs.de vorbei: https://www.sigs.de/autor/bernd.ruecker

Bernd Rücker is a software developer at heart who has been innovating process automation deployed in highly scalable and agile environments of industry leaders such as T-Mobile, Lufthansa, ING, and Atlassian. He contributed to various open-source workflow engines for more than 15 years and is the Co-Founder and Chief Technologist of Camunda – an open-source software company reinventing process automation. He is the author of "Practical Process Automation" and co-author of "Real-Life BPMN". Additionally, he is a regular speaker at conferences around the world and a frequent contributor to several technology publications. He focuses on new process automation paradigms that fit into modern architectures around distributed systems, microservices, domain-driven design, event-driven architecture, and reactive systems.

Mehr Inhalte dieses Speakers? Schaut doch mal bei sigs.de vorbei: https://www.sigs.de/autor/bernd.ruecker

Bernd Rücker
Raum 13b
Bernd Rücker
Raum 13b

Vortrag Teilen

11:00 - 11:45
Do 7.2
No-code does not mean no-model
No-code does not mean no-model

**TL, DR;** Embrace no-code to explore more models and throw most of those models away. You will quickly discover what works, and what matters, in the business process that you are automating. If it matters enough, you can extract it into a high-fidelity design in code.

Target Audience: Everyone with a stake in the software production process
Prerequisites: None
Level: Basic

Extended Abstract:
Many software projects still consume considerable resources, and take a long time before anything material is put in the hands of the end-user. At a smaller scale this happens with teams that have the ambition to adopt Domain-Driven Design principles but that lack the expertise and experience in how to approach the design process. There is a spectrum of mistakes. On one hand there is the lack of producing a meaningful and shared model that is able to unify the conflicts and handle the complexity that the messy world will serve the system. On the other end of that spectrum there is analysis paralysis: a model that never sees the light of day, because there is always a new case it cannot handle. If the team doesn't produce a meaningful model, or if it fails to put that model in front of experts early on, then the team robs itself of precious feedback. "Judge models by their usefulness" is a mantra that is difficult to live by, if the model isn't being used...
Despite warnings, teams design big architectures early on, to support even bigger ambitions of the organization they work for, but they forget that it's not the architecture that the end-user cares about. With every bit of structure that is added early on, the team reduces the degrees of freedom to evolve the system at a later point in time. In order to support long-lasting design that is attuned to the environment, teams should set architectural principles that allow for a helpful structure to emerge, regardless of the platform.
> **No code** has entered the chat...
For a while now, no-code vendors have been telling organizations that they shouldn't be limited by expensive software engineers to build systems that are useful. No-code aims to commoditize the software production process. Commodification of technology leads to value if it removes a limitation, but successful adoption only works if the rules and policies that initially helped us overcome the limitation are replaced as well. Practices such as DevOps have to be adopted in order to reap the benefits of the commodification of compute and storage in the cloud. In order to benefit from serverless, system components need to be decoupled through message-driven designs. In order to benefit from no-code, people have to organize around the software production process in a different way.
Within software engineering communities no-code has been dismissed as a fad, saying the need for writing code will never go away because the needs of most software systems are too complex to capture in a visual design environment. This viewpoint ignores the argument that software engineers act as a gatekeeper, a limitation for the stakeholder to get what they want. It is reductionist to say that no-code means no-code. No-code is as much about no-code, as wireless is about the absence of wires, or serverless is about the absence of servers. No-code means less boilerplate. And no-code does NOT mean no-model.
The inability to deliver meaningful results in a reasonable amount of time is never out of bad intent, it's the consequence of rigidity in the system of work. If there is no room for experiments, for error, for trying again, then we shouldn't be surprised if people attempt moonshots. But if we can reduce the cost of experiments, then we should be able to iterate more, learn faster, and as a consequence produce more value.
Let's explore how no-code is able to remove the time to market of our ideas to explore new models. Join this session to uncover which rules, policies, and practices around modeling and design need to be replaced in order to reap the benefits that no-code has to offer.

Marijn Huizendveld works as an independent software consultant for (corporate) startups and scale-ups within Europe. He studied business school (boring though useful) and moonlighted as a freelance software engineer (limited impact, lots of fun).
After getting stung by the start-up bug he founded a SaaS business in which he was involved for the next 6 years (lots of impact, limited private life). This experience provided him with a realistic perspective on business and firm roots in software architecture. He was at the frontier of event-sourced domain models in PHP and has been actively involved in the DDD community since its revival around 2012.
These days he helps his customers to apply the lessons he picked up along the way, in order to make software that propels organizations forward. To support his clients he develops tools (such as Chameleon) that augment the software delivery process which makes teams more effective. He also laughs at his own jokes, for reasons unknown cause they typically aren’t funny. Join the workshop to see if you agree.

Marijn Huizendveld
Raum 11
Marijn Huizendveld
Raum 11

Vortrag Teilen

14:30 - 15:30
Do 7.3
Misserfolge und Lehren bei der Anwendung von DDD: Beispiele aus der realen Welt
Misserfolge und Lehren bei der Anwendung von DDD: Beispiele aus der realen Welt

DDD ist momentan extrem populär, was zu falschen oder überzogenen Erwartungshaltungen führen kann. Diese werden in meinem Vortrag angesprochen. Ich stelle Ihnen anhand zahlreicher konkreter Beispiele aus der Praxis vor, wie man die meisten Probleme mit DDD vermeiden oder wie man mit DDD erfolgreich arbeiten kann. Dabei werden Facetten aus verschiedensten Blickwinkeln aufgegriffen: Entwicklung, Strategie, Fachmodellierung, Organisation und Agilität.
Der Vortrag soll ein Gespür für den Einsatz von DDD im Kontext Ihrer Organisation vermitteln.

Zielpublikum: Architekt:innen, Entwickler:innen, Manager:innen
Voraussetzungen: Grundverständnis von DDD
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
Domain-Driven Design ist kein Patentrezept und löst kein Problem auf magische Weise. Die Herausforderungen und die Komplexität, die wir mit DDD zu bewältigen versuchen, sind schwierig und es gibt keinen einfachen Lösungsansatz. Nichtsdestotrotz gibt es eine wachsende Popularität und Wertschätzung für das Thema auf dem Markt, was zu überhöhten Erwartungen und schließlich zu Enttäuschungen führen kann.
Der Referent dieses Vortrags arbeitet seit 17 Jahren mit Domain-Driven Design an vielen Softwaresystemen und dieser Vortrag handelt von meinen Erfahrungen mit dem Scheitern. Glauben Sie mir: Ich bin oft gescheitert, aber es gibt immer eine Gelegenheit, etwas daraus zu lernen. Der Vortrag zielt darauf ab, Ihnen die Möglichkeit zu geben, aus den Fehlern von mir als Berater und den Teams/Organisationen, mit denen ich gearbeitet habe, zu lernen.
Der Vortrag behandelt Themen wie:

  1. Domain-Driven Design im Wasserfall
  2. Ignoranz für Code (aka nur Fokus auf strategisches Design)
  3. Übermäßiger Gebrauch von Mustern um ihrer selbst willen
  4. Kulturelle Implikationen
  5. Cargo-Kult
  6. Developer Experience
  7. Eingeschränkte Verfügbarkeit von Fachexperten
  8. Umgang mit etablierten Modellierungstechniken/Methoden
  9. Unkenntnis über die Definitionen/Bedeutung von Heuristiken und Mustern

Dieser Vortrag zielt darauf ab, Ihnen eine Sensibilität für potenzielle Gefahren zu vermitteln, wenn Sie versuchen, DDD für Ihr Team und Ihre Organisation einzuführen, und wird nur reale Situationen beschreiben, die tatsächlich passiert sind. Jeder beschriebene Misserfolg wird mit einer Erkenntnis darüber einhergehen, wie man es besser machen kann.
Es handelt sich um einen interaktiven Vortrag, bei dem Ihnen, dem Publikum, Fragen und Umfragen (über ein Online-Tool) gestellt werden. Sie werden sich beteiligen können.

Michael Plöd ist Fellow bei INNOQ. Seine aktuellen Beratungsschwerpunkte sind Domain-driven Design, Team Topologies, soziotechnische Architekturen und die Transformation von IT-Delivery-Organisationen in Richtung Kollaboration und lose gekoppelter Teams. Michael ist zudem Autor des Buchs „Hands-on Domain-driven Design - by example“ auf Leanpub sowie regelmäßiger Referent auf nationalen und internationalen Konferenzen.

Michael Plöd
Raum 11
Michael Plöd
Raum 11

Vortrag Teilen

17:00 - 18:00
Do 7.4
Wie man so ziemlich alles versteht – Domänenanalyse für Praktiker
Wie man so ziemlich alles versteht – Domänenanalyse für Praktiker

Bei Software steht oft komplexe Fachlichkeit im Mittelpunkt: Medikamentenstudien, Steuerberechnung, Teleskopsteuerung. Idealerweise wollen wir Softwerker ein Tool entwickeln, mit dem Fachexperten selbstständig Studien, Steuerberechnungen oder astronomische Beobachtungen beschreiben können, sodass sie direkt von Software ausführbar sind. Herauszufinden, wie man die Domäne vollständig und präzise beschreibt, ist dabei extrem wichtig. Der Vortrag liefert dafür konkrete Practices, die sich über Jahre bewährt haben, plus Anekdoten aus dem Projektalltag.

Zielpublikum: Product Owner:innen, Requirements Engineers, Architekt:innen
Voraussetzungen: Keine
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
Ich beginne, indem ich nochmal 5 Minuten motiviere, warum man Tools bauen möchte, mit denen Fachler direkt programmieren/spezifizieren/modellieren wollen. Dann beschreibe ich kurz die drei Aspekte der Domänenanalyse: Sammeln, Denken und Validieren. Klingt trivial, ist es irgendwie auch, aber viele der konkreten Practices sind es nicht. Hier sind einige Stichworte, die ich betrachten werde:
Sammeln: Die (Nicht-)Rolle von schriftlichem Material, verborgene Sprachen finden, mit den richtigen Leuten reden, konsistente Terminologie, Workshops richtig durchführen, aktives Zuhören, Umgang mit Ungewissheit, Ergebnisse festhalten.
Denken: Abgrenzung und Tiefe der Domäne, Beseitigung von "historischem Müll", Test-Unterstützung, Plattformen, Hochs und Tiefs, das Wissen verbreiten
Validieren: Spiel-Implementierung der Domäne, Benutzer experimentieren lassen, Konzeptuelle Überprüfung, Umgang mit Feedback, Tolle Demos
Der Vortrag basiert auf dem Buch "How to Understand Almost Anything", das ich im letzten Jahr geschrieben habe.

Markus Völter arbeitet als freiberuflicher Berater für Software-Architektur, domänenspezifische Sprachen und Modellierungswerkzeuge. Die letzten 15 Jahre hat er damit verbracht, die verschiedensten Domänen zu verstehen und deren Fachlichkeit in endbenutzerfreundliche Werkzeuge zu gießen, darunter Medizin, Finanzen und Maschinenbau. Neben der Projektarbeit schreibt Markus über seine Themen in Papers und in Büchern. Er hat Physikalische Technik studiert und hat ein PhD in Informatik.

Markus Völter
Raum 13a
Markus Völter
Raum 13a

Vortrag Teilen

Zurück