Konferenzprogramm

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

Per Klick auf "VORTRAG MERKEN" innerhalb der Vortragsbeschreibungen können Sie sich Ihren eigenen Zeitplan zusammenstellen. Sie können diesen über das Symbol in der rechten oberen Ecke jederzeit einsehen.

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

Track: Use Domain-Driven Design Now!

Nach Tracks filtern
Nach Themen filtern
Alle ausklappen
  • Donnerstag
    03.02.
, (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« und dem www.LeasingNinja.io sowie Übersetzer von »Domain-Driven Design kompakt«.
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

Zurück