Konferenzprogramm

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

Unser Programm gibt es auch als praktische PDF-Datei >>Zum Download

Thema: Domain-Driven Design

Nach Tracks filtern
Nach Themen filtern
Alle ausklappen
  • Montag
    31.01.
  • Dienstag
    01.02.
  • Donnerstag
    03.02.
  • Freitag
    04.02.
, (Montag, 31.Januar 2022)
10:00 - 13:00
Mo 9
Ausgebucht Diversity Verständnis für Unterschiede und Gemeinsamkeiten: Wie viel Gemeinsamkeit braucht es in der Architekturarbeit?
Diversity Verständnis für Unterschiede und Gemeinsamkeiten: Wie viel Gemeinsamkeit braucht es in der Architekturarbeit?

In der Architekturarbeit ist es wichtig, sich auf Gemeinsamkeiten bei den Erwartungen der Stakeholder zu konzentrieren. Der ausschließliche Fokus auf Gemeinsamkeiten führt jedoch oft zur Trennung und Kategorisierung von Stakeholdern - ein guter Boden für Stereotypisierungsprozesse und Konflikte. Die Fokussierung auf Unterschiede und Gemeinsamkeiten zugleich fördert konstruktive Beziehungen und Vertrauen. Für Software Architekten ist es daher hilfreich, mit einem Diversity-Verständnis von Unterschieden und Gemeinsamkeiten zu arbeiten. Denn der Blick auf die Gemeinsamkeiten und Unterschiede macht es oft leichter, mit unterschiedlichen Erwartungen an das zu realisierende IT-System umzugehen. In diesem Workshop wird anhand eines Praxisbeispiels gezeigt, inwieweit ein Verständnis von Diversität ein Erfolgsfaktor für Software Architekten ist.

Maximale Teilnehmerzahl: 20

Zielpublikum: Architekt:innen, Entwickler:innen, Projektleiter:innen, Manager, Entscheider
Voraussetzungen: Basiswissen
Schwierigkeitsgrad: Anfänger

Mahbouba Gharbis berufliches Spektrum umfasst Tätigkeiten als Softwarearchitektin, Trainerin, Systementwicklerin, Reviewerin und Dozentin. Darüber hinaus ist sie CEO der ITech Progress GmbH und hat sich in über 15 Jahren auf die Konzeption und Entwicklung von Softwarearchitekturen mittlerer bis großer Softwaresysteme spezialisiert. Auf dem Gebiet der Architekturbewertung bringt sie jahrelange Berufserfahrung mit sowie die nötige Begeisterung, die sie durch Vorträge an ihre ZuhörerInnen weitergibt. Als Mitgründerin und Vorstandsvorsitzende des International Software Architecture Qualification Board (iSAQB) ist sie außerdem aktiv an der Erstellung einheitlicher Lehr- und Ausbildungspläne für SoftwarearchitektInnen beteiligt.

Verantwortung, Pragmatismus, Fachwissen um die Domäne und Professionalität. Dieses sind die grundlegenden Werte und Attribute, die erfolgreiche Software-Architekt:innen kennzeichnen. Basierend auf langjährigen Projekterfahrungen vermittelt Holger Tiemeyer diese Fähigkeiten und Kenntnisse in seinen Trainings, spricht darüber auf Konferenzen und publiziert Artikel in Fachmagazinen. Als studierter Informatiker mit Nebenfach Psychologie vertritt er in seiner Rolle als Stellvertretender Vorsitzender und Schatzmeister des iSAQB e.V sowohl die finanziellen Belange des Vereins als auch soziale Aspekte rund um die Menschen, die Software-Architekturen gestalten.

Mahbouba Gharbi, Holger Tiemeyer
Mahbouba Gharbi, Holger Tiemeyer
flag VORTRAG MERKEN

Vortrag Teilen

18:30 - 20:00
Nmo 3
Domain-Driven Game Design
Domain-Driven Game Design

After two decades of being a business software developer, a DDD consultant and an Event Storming aficionado, I started to build a game and had no clue how to.
So I modelled the heck out of the game using Event Storming and implemented it using all the DDD patterns, functional and object oriented architecture patterns and even CQRS & Event Sourcing.
Let me show you how much fun it is to build a game, using everything you know about business software and subsequently, how your business software building abilities will improve from building games.

Target Audience: Senior Developers, DDD Enthusiasts, Game Developers, Software Architects
Prerequisites: The will to put the fun back into functioning business software
Level: Advanced

Marco Heimeshoff is a trainer, speaker and software developer from Germany. He organizes KanDDDinsky, a conference about Domain-driven Design and the art of business software and co-founded the german DDD community in 2013 and VirtualDDD.com in 2019. Between consulting companies around the globe and his day job in building health care software, you'll find him speaking at conferences about DDD, socio-technical systems and first principles.
Marco Heimeshoff
Marco Heimeshoff
Vortrag: Nmo 3
flag VORTRAG MERKEN

Vortrag Teilen

, (Dienstag, 01.Februar 2022)
17:45 - 18:45
Di 6.4
Adaptive Systems with Wardley Mapping, Domain-Driven Design, and Team Topologies
Adaptive Systems with Wardley Mapping, Domain-Driven Design, and Team Topologies

In a world of rapid changes and increasing uncertainties, organizations have to continuously adapt and evolve to remain competitive and excel in the market. In such a dynamic business landscape organizations need to design for adaptability. Designing for adaptability requires understanding the landscape organizations are operating in, identifying patterns of change, applying principles for organizational fitness, and making mindful strategic decisions to adapt change.

Target Audience: Software Architects, Tech Leads, Engineering Manager, VP of Engineering
Level: Basic

Extended Abstract
Organizations need to aim for building systems and team organizations aligned to the business needs and business strategy and evolving them for adaptability to new changes and unknown environments.
This talk brings different perspectives and techniques together from business strategy (Wardley Mapping), software architecture (Domain-Driven Design), and team organization (Team Topologies) as a powerful toolset to design, build and evolve adaptive systems and team structures for a fast flow of change.

Susanne Kaiser is an independent tech consultant supporting organizations to build and run software products from idea to production with a focus on socio-technical systems. Susanne was previously working as a startup CTO. She has a background in computer sciences and experience in software development and software architecture for more than 18 years. Susanne presents regularly at international tech conferences as a speaker.
, (Donnerstag, 03.Februar 2022)
09:00 - 10:45
Do 8.1
Domain-Driven Design für Legacy-Systeme
Domain-Driven Design für Legacy-Systeme

Auch Legacy-Systeme kann man mit Domain-driven Design (DDD) verbessern. Am Anfang sollte die Frage stehen, warum ein erfolgreiches Legacy-System überhaupt verbessert werden soll. Der Vortrag zeigt, wie man sich dazu an Änderungen des Geschäftsmodells orientieren kann. Technische Ansätze wie das Extrahieren von Bounded Contexts oder die Implementierung von Bubble Bounded Contexts verdeutlichen zudem, wie man ganz praktisch vorgehen kann. So kann DDD auch bei der Anpassung existierender Systeme an sich ständig ändernde Anforderungen helfen.

Zielpublikum: Technische Projektleiter:innen, Architekt:innen, Entwickler:innen
Voraussetzungen: Grundlegendes Verständnis über Softwareentwickung
Schwierigkeitsgrad: Anfänger

Eberhard Wolff ist Fellow bei INNOQ und arbeitet seit mehr als fünfzehn Jahren als Architekt und Berater, oft an der Schnittstelle zwischen Business und Technologie. Er ist Autor zahlreicher Artikel und Bücher, u.a. zu Continuous Delivery und Microservices und trägt regelmäßig als Sprecher auf internationalen Konferenzen vor. Sein technologischer Schwerpunkt sind moderne Architektur- und Entwicklungsansätze wie Cloud, Continuous Delivery, DevOps und Microservices.

Domain Driven Transformation – über den Umbau von IT-Landschaften mit DDD
Domain Driven Transformation – über den Umbau von IT-Landschaften mit DDD

In den letzten Jahren erfahren IT-Landschaften durch Digitalisierung einen großen Änderungsdruck. Für ältere IT-Landschaften bedeutet dies eine komplette strategische Neuausrichtung. In diesem Beitrag schlagen wir mit Domain Driven Transformation eine Methodik vor, in der DDD mit Methoden des EAMs (Enterprise Architecture Management) kombiniert wird. Im Kern liegt die Definition von Bounded Contexts und einer Context Map, die mit der IST-IT-Landschaft abgeglichen werden kann. Aus dem Abgleich entstehen Handlungsfelder, die priorisiert und in eine Roadmap aufgenommen werden.

Zielpublikum: IT-Architekt:innen, IT-Manager und Projektleiter:innen
Voraussetzungen: Grundsätzliches Verständnis von DDD und EAMs
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract
In den letzten Jahren erfahren die IT-Landschaften von Unternehmen einen immer größeren Druck auf notwendige Veränderungen. Dies hat mehrere Gründe:
- Die Cloud verspricht viele Vorteile, aber die vorhandenen, veralteten Technologien verhindern eine Nutzung
- Die Digitalisierung des Business von Firmen führt zu einem Bedarf an schnellen und größeren Änderungen sowie Erweiterungen in der IT-Landschaft
- The 'war of talents' verlangt nach der Nutzung von modernen Technologien, um Talente im Unternehmen zu halten oder einstellen zu können
Für ältere IT-Landschaften bedeutet dies häufig eine komplette strategische Neuausrichtung mit dem Fokus, eine Zielarchitektur zu definieren und einen Plan für die Transformation der IT-Landschaft aufzustellen. Damit die Vorteile der modernen Technologien und Organisation (Cloud-Technologie, DevOps) schnell genutzt werden können, müssen Handlungsfelder priorisiert werden und die Umbauschritte mit dem Projektportfolio und dem EAM verzahnt werden. Ziel des Planungsprojekts ist die Definition einer Zielarchitektur, eine allgemeine Vorgehensweise sowie eine Roadmap, mit deren Hilfe die IT-Landschaft schrittweise in den nächsten Jahren umgebaut werden kann. Und dabei sollen möglichst schnell Benefits hinsichtlich der anfangs genannten Punkte erreicht werden.
In diesem Beitrag werden zunächst die Ausgangslage und die Ziele eines Planungsprojekts erläutert. Dazu schlagen wir eine an die DDD angelegte Methodik vor: Domain Driven Transformation, eine Methodik, in der DDD mit Methoden des EAMs und Projektmanagements kombiniert werden. Im Kern liegt die Definition von Bounded Contexts und einer Context Map, die zum Bedarf des Business passt und mit der derzeitigen IT-Landschaft abgeglichen werden kann. Aus dem Abgleich entstehen Handlungsfelder, die priorisiert und in eine Roadmap aufgenommen werden. Um überhaupt zu einem guten Aufsatzpunkt für DDD zu kommen, muss der Soll-Bedarf des Business definiert werden. Dazu werden capability maps, Prozesslandkarten und Business-Strategien analysiert und damit die gesamte zu betrachtende fachliche Welt aufgespannt. In diesem aufgespannten Feld dienen zunächst Orientierungsszenarien mit Hilfe von Domain Stories dazu, die fachliche Welt näher zu definieren.
In einem spiralförmigen Prozess aus business capabilities, Prozesslandkarte und Domain Stories wird das Feld tiefer erschlossen und Subdomänen werden erkannt. Die daraus definierten Bounded Contexts werden zusammen mit Make-or-buy-Entscheidungen zu einer Zielarchitektur zusammengefasst und mit der IT-Landschaft abgeglichen. Die Handlungsfelder umfassen Redesign-Vorhaben von Applikationen, Modernisierungen, Entrümpelung von nicht mehr benötigten System(teil)en sowie Abschaltung und Einführung von Kaufsoftware zusammen mit der notwendigen Integration.
Der Umbau der IT-Landschaft ist ein über mehrere Jahre andauernder Prozess, der im Sinne einer gesteuerten Evolution immer wieder vom Business-Bedarf über die Zielarchitektur bis zur Priorisierung angepasst werden muss. Die Dokumentation und das Handwerkszeug aus dem obigen Vorgehen eignen sich gut, die Zielarchitektur und die Priorisierungen auf dem Weg der Transformation anzupassen.

Dr. Sönke J. Magnussen begann seine Karriere nach Studium und Promotion der Informatik bei der Deutschen Lufthansa als ABAP & Java-Entwickler sowie als Software-Architekt. Als Manager verantwortete er mehrere Teams für den Betrieb und die Weiterentwicklung von IT-Landschaften. Im Rahmen dieser Führungsfunktionen leitete er mehrere Digitalisierungsvorhaben sowie Redesign- und Einführungsprojekte für die Neuausrichtung von IT-Landschaften auf Digitalisierungs- und Cloud-Strategien. Als IT-Architekt und Consultant bei der WPS – Workplace Solutions hilft er jetzt Teams, IT-Landschaften auf die Zukunft auszurichten.

Henning liebt Programmieren in hoher Qualität. Diese Leidenschaft lebt er als Coder, Coach und Consultant bei der WPS - Workplace Solutions aus. Dort hilft er Teams dabei, Ihre gewachsenen Monolithen zu strukturieren oder neue Systeme von Anfang an mit einer tragfähigen Architektur zu errichten. Häufig kommen dann Microservices oder Self-Contained Systems heraus. Henning ist Autor von »Domain Storytelling« (Addison-Wesley) und dem www.LeasingNinja.io sowie Übersetzer von »Domain-Driven Design kompakt« (dpunkt).

Eberhard Wolff
Sönke Magnussen, Henning Schwentner
Sönke Magnussen, Henning Schwentner
flag VORTRAG MERKEN

Vortrag Teilen

11:00 - 11:45
Do 8.2
What Do You Mean?
What Do You Mean?

The world in which a software system lives is filled with meaning. The structure, concepts and names that inform the code, its changes and the mental models held by developers are expressions of meaning. The very act of development is an exercise in meaning — it's discovery, its formulation, its communication.
But just because we are immersed in concepts of meaning from an early age, and just because the daily work of software development is about wrangling meaning, that doesn't mean we're necessarily good at it. Let's talk about what we mean.

Target Audience: Developers, Architects, UX, Product Owners
Prerequisites: No specific prerequisites
Level: Advanced

Extended Abstract
"It's just semantics." How many conversations about philosophy, politics and programming are derailed by this thought-stopping comment?
Semantics is all about meaning. If there is one thing we struggle with and need to get better at, it is the search for and clarification of meaning. The world in which a software system lives is filled with meaning. The structure, concepts and names that inform the code, its changes and the mental models held by developers are expressions of meaning. The very act of development is an exercise in meaning — it's discovery, its formulation, its communication. Paradigms, processes and practices are anchored in different ways of thinking about and arriving at meaning.
But just because we are immersed in concepts of meaning from an early age, and just because the daily work of software development is about wrangling meaning, and just because it's just semantics, that doesn't mean we're necessarily good at it. It takes effort and insight. Let's talk about what we mean.

Kevlin Henney is an independent consultant, speaker, writer, reviewer, and trainer. His development interests are in programming, people and practice. He is co-author of “A Pattern Language for Distributed Computing” and “On Patterns and Pattern Languages”, two volumes in the Pattern-Oriented Software Architecture series, and editor of “97 Things Every Programmer Should Know” and co-editor of “97 Things Every Java Programmer Should Know”.
Kevlin Henney
Kevlin Henney
flag VORTRAG MERKEN

Vortrag Teilen

14:30 - 15:30
Do 8.3
Collaborative Modelling Domain Boundaries
Collaborative Modelling Domain Boundaries

Within DDD we have the perspective of strategic design where we can split a large-system into multiple sub-domains, each having its purpose and responsibilities, where teams can work in autonomous, clean bounded contexts. One of the most effective ways to define these boundaries is by collaborative modelling with all the stakeholders involved in these domains. Join us were we share war stories about our experience doing collaborative modelling in several companies with 30+ people.

Target Audience: Architects, Manager, Decision Makers, Tech Leads
Prerequisites: None
Level: Advanced

Extended Abstract
As a business, we want to make sure our software can handle changes when the business changes. We want to define boundaries that support the flow of the business value. Within Domain-Driven Design we have the perspective of strategic design. A perspective where we can split a large-system into multiple sub-domains, each having its purpose and responsibilities. Within these sub-domains, teams can work in autonomous, clean bounded contexts. One of the most effective ways to define these boundaries is by collaborative modelling with all the stakeholders involved in these domains. But that poses real challenges: What exactly is the definition of a (sub)domain? What is problem space? How can we form a common language of these boundaries? How does a customer journey fit in? And how do you decide and come to a single model in a large group, where everyone shares that same model on a high level?
Join us in this talk where we will show and tell war stories about our experience of having done collaborative modelling in several companies. We will tell our successes, but more importantly our failures and what we learned from them. What are the key heuristics we think that makes a collaborative modelling session with 30+ people, without any DDD knowledge, succeed? What are the skills we need to learn to facilitate it, and how can we make a company not dependent on us as consultants to continue their journey? You will leave with the knowledge of how to start your own collaborative modelling of your domain boundaries. We tell you our definition of (sub)domains, problems and solution space, and how we explained it to the companies we consulted. Providing you with new perspectives on how to embed this as a ritual in your company.

Leveraging Deep Democracy, Domain-Driven Design, Continuous Delivery and visual collaborate tools, Kenny Baas-Schwegler empowers organisations, teams and people in building valuable software products.
Successful software delivery organizations can balance investments in people and technology. As a strategic software delivery consultant, Paul de Raaij is coaching leadership in designing and evolving the best environment for employees to thrive in. Using a mixture of social sciences, technology and management knowledge to bring new perspectives to our clients given their context.
Kenny Baas-Schwegler, Paul de Raaij
Kenny Baas-Schwegler, Paul de Raaij
flag VORTRAG MERKEN

Vortrag Teilen

17:00 - 18:00
Do 8.4
Visualisierung soziotechnischer Architekturen mit Team Topologies und Context Maps
Visualisierung soziotechnischer Architekturen mit Team Topologies und Context Maps

Soziotechnische Architekturen verheiraten organisatorische und strukturelle Betrachtungen auf Software-Architekturen. Um dieses Geflecht zu visualisieren, haben sich in den letzten Jahren zwei Techniken etabliert: Context Maps aus dem strategischen DDD und Team Topologies von Matthew Skelton und Manuel Pais. Dieser Vortrag stellt beide Ansätze vor und zeigt, wie diese zusammen genutzt werden können, um verschiedene Perspektiven und Fragestellungen auf den Themenkomplex Architektur / Organisation greifbar zu machen.

Zielpublikum:
Architekt:innen, Entscheider:innen, Manager, Projektleiter:innen
Voraussetzungen: Grundlagen Architektur
Schwierigkeitsgrad: Fortgeschritten

Michael Plöd ist Fellow bei INNOQ. Seine aktuellen Interessengebiete sind Microservices, Domain-driven Design, Alternativen zu alt eingewachsenen Software-Architekturen, Event Sourcing und Präsentationstechniken für Entwickler und Architekten. Michael ist zudem Autor des Buchs „Hands-on Domain-driven Design - by example“ auf Leanpub.

Michael Plöd
Michael Plöd
flag VORTRAG MERKEN

Vortrag Teilen

, (Freitag, 04.Februar 2022)
09:00 - 16:00
Fr 3
Ausgebucht Facilitating Collaborative Design Decisions
Facilitating Collaborative Design Decisions

If we want to make sustainable design decisions for our architecture that are embraced by everyone, the most effective way is to do this collaboratively. It is hard to do because we need to deal with all sorts of group dynamics that cause people to stop sharing what they want, ending up in resistance behaviour from sarcastic jokes, to stopped communication. So how can we make collaborative design decisions better? Join us in this hands-on workshop where we explore different models of decision making.

Maximum number of participants: 24

Target Audience: Architects, Managers, Decision Makers
Prerequisites: None
Level: Expert

Extended Abstract
If we want to make sustainable design decisions for our architecture that are embraced by everyone, the most effective way is to do this collaboratively. Everyone can feel a part of the decision, and can potentially give the input they have. The group is aligned and knows what is to be expected onward. On paper this sounds great, but in reality we know it is hard to do because we need to deal with all sorts of group dynamics. Dynamics like cultural differences, conflicts of opinions, cognitive biases, and polarities that the group are part of. These dynamics cause people to stop sharing what they want, which ends up in resistance behaviour from sarcastic jokes, to stopped communication or leaving the session. No wonder a lot of people resort to a more autocratic form of decision making, where the architect analyzes and makes the decision. So how can we make collaborative design decisions better?

Join Gien, Evelyn and Kenny in this hands-on workshop where we explore different models of decision making that can help facilitate collaborative design decisions. We will dive into a variety of facilitation techniques such as:

  • Working with climate reports to trigger hidden group conflicts
  • Visualising trade-offs of different models with the pro-con-fix list
  • Taking group decisions with full buy in with Deep Democracy
Leveraging Deep Democracy, Domain-Driven Design, Continuous Delivery and visual collaborate tools, Kenny Baas-Schwegler empowers organisations, teams and people in building valuable software products.
Gien Verschatse, a software developer with 10 years of experience, mainly in a .NET environment, who likes to start her day with coffee. She specialises in bridging the gap between users and developers by practicing domain driven design. Besides that she loves to learn how teams can improve the way they make decisions both on a technical and organisational level. She is a strong believer of continuously learning by deliberate practice and knowledge sharing, which is why she dedicates a lot of her free time speaking at conferences or user groups.She also helps to organise an F# conference in the US, Open FSharp. When she is not busy with all of the above, you will find her on the sofa, reading a book (yes, with coffee).
Evelyn van Kelle is a strategic software delivery consultant, with experience in coaching, advising and guiding organisations and teams in designing socio-technical systems.
Kenny Baas-Schwegler, Gien Verschatse, Evelyn van Kelle
Kenny Baas-Schwegler, Gien Verschatse, Evelyn van Kelle
flag VORTRAG MERKEN

Vortrag Teilen

09:00 - 16:00
Fr 5
Domain-Driven Design-Tutorial: DDD intensiv
Domain-Driven Design-Tutorial: DDD intensiv

In den Zeiten von Microservices wird klar, wie wichtig Domain-Driven Design nach wie vor ist. Denn nur mit Strategischem Design und dem Aufteilen der Domäne in Bounded Contexts kann ein sinnvoller (nämlich fachlicher) Schnitt für die Microservices gefunden werden.

Aber auch Taktisches Design mit der Ubiquitous Language und den Building Blocks haben nichts an Aktualität verloren.

In diesem Workshop nehmen wir uns einen Tag Zeit, um DDD näher anzuschauen. Der Workshop besteht aus abwechselnd Vortrag, Diskussion und Übungen.

Zielpublikum: Architekt:innen, Entwickler:innen, Projektleiter:innen, Manager, Entscheider, POs, Fachexpert:innen
Voraussetzungen: Erfahrung in mittleren bis großen Projekten
Schwierigkeitsgrad: Anfänger

Extended Abstract
In den Zeiten von Microservices wird klar, wie wichtig Domain-Driven Design (DDD) nach wie vor ist. Denn nur mit Strategischem Design (also DDD im Großen) und dem Aufteilen der Domäne in Bounded Contexts kann ein sinnvoller (nämlich fachlicher) Schnitt für die Microservices gefunden werden.

Aber auch Taktisches Design (also DDD im Kleinen) mit der Ubiquitous Language und den "Building Blocks" Entities, Value Objects, Aggregates, Services und Co. haben nichts an Aktualität verloren.

In diesem Workshop nehmen wir uns einen Tag Zeit, um DDD näher anzuschauen. Der Workshop besteht aus abwechselnd Vortrag, Diskussion und Übungen.

Der Aufbau wird so sein, dass wir zunächst einen Überblick über DDD geben und uns dann die einzelnen Themen detailliert betrachten. Dabei nähern wir uns DDD gewissermaßen von außen nach innen. Inhaltlicher Aufbau:

  1. Einführung und Überblick
  2. Domäne kennenlernen
  3. Domäne aufteilen
  4. Sprache lernen und bauen
  5. Domäne modellieren
  6. Modell implementieren

Henning liebt Programmieren in hoher Qualität. Diese Leidenschaft lebt er als Coder, Coach und Consultant bei der WPS - Workplace Solutions aus. Dort hilft er Teams dabei, Ihre gewachsenen Monolithen zu strukturieren oder neue Systeme von Anfang an mit einer tragfähigen Architektur zu errichten. Häufig kommen dann Microservices oder Self-Contained Systems heraus. Henning ist Autor von »Domain Storytelling« (Addison-Wesley) und dem www.LeasingNinja.io sowie Übersetzer von »Domain-Driven Design kompakt« (dpunkt).

Henning Schwentner
Henning Schwentner
flag VORTRAG MERKEN

Vortrag Teilen

Zurück