Hinweis: Die aktuelle OOP-Konferenz finden Sie hier!

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: Microservices

Nach Tracks filtern
Nach Themen filtern
Alle ausklappen
  • Montag
    31.01.
  • Dienstag
    01.02.
  • Mittwoch
    02.02.
  • Donnerstag
    03.02.
  • Freitag
    04.02.
, (Montag, 31.Januar 2022)
18:30 - 20:00
Nmo 1
Wenn "Microservice-Architektur" die Antwort ist, was war dann eigentlich die Frage?
Wenn "Microservice-Architektur" die Antwort ist, was war dann eigentlich die Frage?

Als Entwickler kann man ihnen fast nicht ausweichen – den Microservice-Architekturen. Die Entscheidung für deren Einsatz ist oft schon getroffen, bevor es die erste User-Story im Backlog und die erste Zeile Code im Repository gibt.
„Microservice“ lautet scheinbar die Antwort auf alle Fragen nach der besten Umsetzung heutiger Business-Probleme. Netflix und andere dienen als schillerndes Beispiel für den Erfolg dieser Architektur.
Aber sind sie wirklich der einzige Weg ins Ziel? Sind sie Fluch oder Segen? Dem wollen wir auf den Grund gehen.

Zielpublikum: Entwickler:innen, Architekt:innen, Entscheider mit technischem Background
Voraussetzungen: Kenntnisse in Java oder einer anderen objektorientierten Sprache, Grundkenntnisse in Software-Architektur
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract
Als Entwickler kann man ihnen fast nicht ausweichen – den Microservice-Architekturen. Egal ob Neuauflage einer Bestandsanwendung oder Green-Field-Projekt, der Architektur-Ansatz ist oft schon festgelegt, bevor es die erste User-Story im Backlog und die erste Zeile Code im Repository gibt.
„Microservice“ lautet scheinbar die Antwort auf alle Fragen nach der besten Umsetzung heutiger Business-Probleme. Unternehmen wie Netflix dienen als schillerndes Beispiel für den Erfolg dieser Architektur. Und alle wollen nacheifern. Mit modernen Tools, agilen Methoden und motivierten Entwicklern wird das schon zu schaffen sein.
Aber was waren eigentlich die Architektur-Zziele, die zur Entscheidung geführt haben? Und welche Alternativen hätte es gegeben? Was sind die Kernprobleme, die wir lösen müssen? Und sind Microservices wirklich der einzige Weg ins Ziel? Oder wieso wurden sie gewählt?
Wir haben uns angeschaut, warum Vergleiche mit Netflix hinken, warum Microservice-Architekturen sich oft zu mehr Fluch als Segen entwickeln und dass die Rolle der Entwickler bei diesem Scheitern oft unterschätzt wird.

Tilmann Glaser ist freiberuflicher Software Engineer. Als iSAQB zertifizierter Software-Architekt betreut er Entwicklungsprojekte und unterstützt Teams als Mentor für agile Software-Engineering-Methoden (ASE). Dabei ist ihm wichtig, selbst mit anzupacken und als Teil der Teams aktiv an der Software-Entwicklung teilzunehmen. Seine mehr als fünfzehn Jahre Erfahrung in verschiedenen Rollen in IT-Projekten bringt er gerne ein, um neue Blickwinkel aufzuzeigen. Seine Kernthemen sind agile Transition, Architektur in agilen und klassischen Umfeldern, Clean Code, Test-Driven Development (TDD) und Project Recovery.

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

Peter Fichtner ist seit 1995 bei Atruvia in Karlsruhe tätig. Nach über zehn Jahren in der Anwendungsentwicklung und weiteren 10 Jahren in der Architektur greift er auf breitgefächerte Erfahrungen im Java-Umfeld zurück. Aktuell fokussiert er die Themen Test-Driven-Development (TDD), Continuous Integration (CI), Clean Code (CC) sowie agile Entwicklungsmethoden. In seiner Rolle als Coach für agiles Softwareengineering (ASE) unterstützt Peter Fichtner seit acht Jahren agile und nicht-agile Teams bei Atruvia mit Schulungen und Coachings.
Tilmann Glaser, Peter Fichtner
Tilmann Glaser, Peter Fichtner
flag VORTRAG MERKEN

Vortrag Teilen

, (Dienstag, 01.Februar 2022)
09:00 - 10:45
Di 8.1
Qualität verbessern mit Gamification
Qualität verbessern mit Gamification

Gamification bringt Spaß in den Projektalltag. Aber lohnt es sich überhaupt?
Um dies einschätzen zu können, geben wir einen Überblick über verschiedene spielerische Ansätze, die auf die Qualitätssicherung von Software fokussieren.
Wir gehen darauf ein, wie man Gamification gezielt und im richtigen Maß in Projekte einführt, welche Schwerpunkte gesetzt werden sollten und wie skeptische Kollegen überzeugt werden können.
Damit kann der Vortrag als Entscheidungsgrundlage dienen. Richtig eingesetzt, lohnt sich Gamification!

Zielpublikum: Projektleiter:innen, Manager, Entscheider
Voraussetzungen: Projekterfahrung
Schwierigkeitsgrad: Anfänger

Extended Abstract

Spielerische Ansätze in der Software-Entwicklung sind nicht neu und finden immer häufiger ihren Platz im Projektalltag. Doch kosten diese nicht einfach nur Zeit und Geld? Bringt es überhaupt Vorteile, das Team „spielen“ zu lassen? Und wie misst man Erfolg oder auch das Scheitern einer Spielidee?
Wir zeigen am Beispiel von Gamification-Ansätzen in der Qualitätssicherung, dass diese das Potenzial haben, nicht nur den Projektalltag aufzulockern und den Teamzusammenhalt zu stärken, sondern auch die Softwarequalität spielend zu verbessern. Gezielte Produktverbesserung, z. B. durch Bug-Hunting, wird ebenso adressiert wie systematische Prozessverbesserung, z. B. durch Maturity Poker.
Voraussetzung ist, dass Gamification gezielt eingesetzt wird, um effizient zu sein. Der spielerische Ansatz muss zum Team und zum Projekt passen, Schwächen beheben und auf Lösungen für bestehende Probleme fokussieren.
Der Vortrag will eine Entscheidungshilfe geben, wann sich spielerische Ansätze lohnen und wann man eher auf sie verzichten sollte. Denn nur, wenn sich Erfolge einstellen und Gamification das Projekt voranbringt, stehen alle Beteiligten hinter dem Vorgehen, und die investierte Zeit ist nicht „verspielt".

Dehla Sokenou fühlt sich in allen Phasen der Software-Entwicklung zu Hause, besonders im Testen. Bei WPS - Workplace Solutions ist sie als Test- und Qualitätsmanagerin und Software-Architektin tätig.

Mehr Inhalte dieses Speakers? Schaut doch mal bei SIGS.de vorbei: https://www.sigs.de/experten/dehla-sokenou/

Baris Güldali begleitet als Agile Coach und Quality Coach agile Teams und unterstützt diese bei der Erreichung ihrer Sprintziele. Er organisiert Community-Events mit Schwerpunkt Agilität und Qualität.

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

Supersonic Subatomic Mocking: Testen einer Quarkus-App mit Kotlin, JUnit und MockK
Supersonic Subatomic Mocking: Testen einer Quarkus-App mit Kotlin, JUnit und MockK

Schon von Quarkus gehört, dem neuen und effizienten JVM-Framework? Das - nicht unerfolgreich - etablierten Frameworks wie Spring Boot Konkurrenz macht?
Und bist Du daran interessiert, wie man eine Quarkus-App erstellt und - noch wichtiger - Teile davon isoliert testet?
Interessiert? Dann lass mich von unseren Erfahrungen berichten, wie sich Quarkus-Apps mit Kotlin, JUnit und MockK testen lassen. Praktische Einblicke garantiert!

Zielpublikum: Developers
Voraussetzungen: Basic knowledge about JVM languages, JVM frameworks and the microservice architecture pattern
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract
Das relativ junge Quarkus konnte sich zu einem ernst zu nehmenden Konkurrenten für etablierte Microservice-Frameworks wie Spring Boot entwickeln. Das liegt insbesondere daran, dass das leistungsfähige und dennoch leichtgewichtige JVM-Framework es schafft, Startzeiten und Speicherverbrauch von Anwendungen erheblich zu reduzieren. Damit ist es nicht nur für die Entwicklung von Microservices in containerisierten Cloud-Plattformen wie Kubernetes interessant, sondern auch für Serverless Computing.
Und es unterstützt meine Lieblings-Programmiersprache: Kotlin!
Wenn man eine Anwendung mit Quarkus und Kotlin entwickelt, kommt man früher oder später (hoffentlich früher ;-) ) nicht umhin, isolierte Tests zu schreiben. Nur so lässt sich bekanntermaßen automatisiert feststellen, ob sich der Anwendungscode wie erwartet verhält. Und als Kotlin-Entwickler will man dazu bekannte Technologien wie z. B. JUnit und MockK nutzen. Es gibt dabei aber einige wesentliche Aspekte, die beim Testen und Mocking von CDI-Beans in Quarkus beachtet werden müssen.
Interessiert? Dann habt teil an unseren Erfahrungen, wie sich Quarkus-Apps mit Kotlin, JUnit und MockK testen lassen. Praktische Einblicke garantiert!

In seiner Tätigkeit für die Novatec Consulting GmbH unterstützt Christian Schwörer Kunden bei der digitalen Transformation hin zu verteilten, Cloud-basierten (Microservice-)Architekturen. Dabei setzt er häufig und gerne Spring Boot/Cloud ein, zunehmend aber auch andere Frameworks wie Micronaut, Ktor oder Quarkus. Er ist der Überzeugung, dass sich die praktische Auseinandersetzung mit dem Thema für jeden Architekten und Entwickler lohnt – auch wenn Microservices und Serverless sicher nicht die "Silver Bullet" für alle Probleme des Software-Engineerings sind und daher ganz gezielt eingesetzt werden sollten.
Dehla Sokenou, Baris Güldali
Christian Schwörer
Dehla Sokenou, Baris Güldali

Vortrag Teilen

Christian Schwörer
flag VORTRAG MERKEN

Vortrag Teilen

17:45 - 18:45
Di 3.4
Turmbau zu Babel in nachrichtenbasierten Systemen
Turmbau zu Babel in nachrichtenbasierten Systemen

Der verstärkte Einsatz von Microservices führt zu einer erhöhten Kommunikation zwischen den Systemkomponenten. Bei der technischen Realisierung sind REST-Schnittstellen für die synchrone und Message Broker für die asynchrone Informationsverteilung weit verbreitet. Wenn es aber um den Inhalt und die syntaktische Struktur der Nachrichten geht, kann es leicht zu einer babylonischen Sprachverwirrung kommen. In diesem Vortrag betrachten wir verschiedene Ansätze, um einer solchen Sprachverwirrung Einhalt zu gebieten.

Zielpublikum: Architekt:innen, Entwickler:innen
Voraussetzungen: Projekterfahrung
Schwierigkeitsgrad: Anfänger

Extended Abstract
Der verstärkte Einsatz von Microservices führt zu einer erhöhten Kommunikation zwischen den Systemkomponenten. Bei der technischen Realisierung sind mittlerweile REST-Schnittstellen für die synchrone und Message Broker für die asynchrone Informationsverteilung weit verbreitet. Wenn es aber um den Inhalt und die syntaktische Struktur der Nachrichten geht, kann es leicht zu einer babylonischen Sprachverwirrung kommen.
„Ach, das Feld. Ne, das haben wir doch umbenannt“ oder „Dieses Feld haben wir doch schon vor Wochen entfernt und dies über … bekannt gegeben“ dürften bekannte Sätze sein, wenn man den Gesprächen der beteiligten Entwickler lauscht.
In diesem Vortrag möchte ich vor allem im Hinblick auf einen asynchronen Nachrichtenaustausch einige Ansätze betrachten, um einer solchen Sprachverwirrung Einhalt zu gebieten. Anschließend werden wir einen Blick auf die schema-basierte Lösung werfen, die wir im aktuellen Projekt einsetzen.

Kristian Kottke ist als Lead Software Developer für die iteratec GmbH in verschiedenen Projekten und Branchen tätig. Er beschäftigt sich mit Software-Architekturen sowie unterschiedlichen Technologiestacks, wobei seine Interessen insbesondere in den Bereichen Big-Data- und NoSQL-Technologien liegen
Kristian Kottke
Kristian Kottke
flag VORTRAG MERKEN

Vortrag Teilen

, (Mittwoch, 02.Februar 2022)
09:00 - 10:30
Mi 1.1
Shared Data in verteilten Architekturen
Shared Data in verteilten Architekturen


Eine auf Microservices basierende Architektur umzusetzen, bedeutet, dass auch die Datenhaltung auf die verschiedenen Services verteilt werden muss. Was aber bedeutet das in der Praxis? Was ist, wenn Daten einer Entität - vollständig oder in Teilen - in mehreren Services benötigt werden? Wie wird referenzielle Integrität über mehrere Services hinweg realisiert? Wie lassen sich serviceübergreifende Transaktionen realisieren? Dies sind nur einige von vielen Fragen, die im Rahmen der Session beantwortet werden. So viel vorab: Umdenken ist gefragt!

Zielpublikum: Architekt:innen, Entwickler:innen, Projektleiter:innen, Manager, Entscheider
Voraussetzungen: Kenntnisse Microservices
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract

Nur wenn die Auftrennung der Fachlichkeit in verschiedenen Microservices auch konsequent bis hin zur Ebene der Datenhaltung vollzogen wird, kann die angestrebte Unabhängigkeit der Services zur Entwicklungs- und Laufzeit erreicht werden. Ohne diesen Schritt dagegen würde sich das Problem der starren Kopplung und der damit einhergehenden Abhängigkeiten einer monolithischen Architektur lediglich um eine Schicht nach unten, in die Datenbank, verlagern. Was aber bedeutet das konsequente Einhalten des Database-per-Service-Patterns und einer damit einhergehenden Verteilung der Datenhaltung in der Praxis? Die Session zeigt die wesentlichen Herausforderungen auf und liefert passende Lösungsansätze.

Lars Röwekamp, Gründer des IT-Beratungs- und Entwicklungsunternehmens open knowledge GmbH, beschäftigt sich im Rahmen seiner Tätigkeit als „CIO New Technologies“ mit der eingehenden Analyse und Bewertung neuer Software- und Technologietrends. Ein besonderer Schwerpunkt seiner Arbeit liegt derzeit in den Bereichen Enterprise und Cloud Computing sowie ML/AI, wobei neben Design- und Architekturfragen insbesondere die Real-Life-Aspekte im Fokus seiner Betrachtung stehen.

Lars Röwekamp
Lars Röwekamp
flag VORTRAG MERKEN

Vortrag Teilen

14:30 - 15:30
Mi 3.3
Vom zentralen Security Gateway zu verteilten Microgateways
Vom zentralen Security Gateway zu verteilten Microgateways

Mit Microservice-Architekturen & DevOps-Prozessen werden große zentrale Security Gateway-Installationen zunehmend in Frage gestellt. Die notwendige Koordination zwischen Anwendungsverantwortlichen, Administratoren, Entwicklern & Security führt zu Effizienzverlusten und Frustration. Besser wäre es, Security-Aufgaben mittels Microgateways zu erledigen. Der Vortrag beleuchtet technische und organisatorische Herausforderungen von Microgateways und zeigt in einer Demo, wie Microgateways genutzt werden können, um existierende Services zu schützen.

Zielpublikum: Architekt:innen, Entwickler:innen
Voraussetzungen: Projekterfahrung
Schwierigkeitsgrad: Anfänger

Extended Abstract
Mit dem Aufkommen von Microservice-Architekturen und DevOps-Prozessen werden große zentrale Security Gateway-Installationen zunehmend in Frage gestellt. Die notwendige Koordination zwischen Anwendungsverantwortlichen, Administratoren, Entwicklern und dem Security-Team führt zu Effizienzverlusten und Frustration. Besser wäre es, wenn Security-Aufgaben nahe bei den zu schützenden Services mittels sogenannter Microgateways erledigt würden. DevOps-Teams könnten die Verantwortung für die Sicherheit ihrer Services von der ersten Minute an bis in die Produktion übernehmen (Shift Left). Der Vortrag beleuchtet technische und organisatorische Herausforderungen rund um den Einsatz von Microgateways. Zudem wird in einer Demo gezeigt, wie Microgateways konkret genutzt werden können, um existierende Services zu schützen.

Stefan Dietiker ist seit 10 Jahren im Professional Services, nimmt Projekte wahr, arbeitet bei der Quality Assurance und im Requirements Engineering der Web Application Firewall mit. Er setzte Projekte im Bereich Cloud und Containerlösungen um. Vorher war er als Engineer und technischer Projektleiter in der Telekommunikation und für Industrielösungen tätig. Er ist Dipl.-Ing. FH und hat ein Zertifikat als CISSP (Certified Information Systems Security Professional) und AWS Certified Solution Architect Associate.
Stefan Dietiker
Stefan Dietiker
Vortrag: Mi 3.3
flag VORTRAG MERKEN

Vortrag Teilen

17:00 - 18:00
Mi 1.4
7 Missverständnisse zu Software- Architektur
7 Missverständnisse zu Software- Architektur

In den letzten 30 Jahren habe ich viel Software selbst oder mit Teams entwickelt und viele Softwaresysteme analysiert, um die darin angesammelten technischen Schulden zu analysieren und Lösungen zu erarbeiten. Dabei bin ich immer wieder ähnlichen Missverständnissen rund um das Thema Software-Architektur begegnet. Dieser Vortrag wird klären, welche Missverständnisse das sind und warum sie anders gedacht werden müssen, damit wir mit unseren Software-Architekturen kleine und große Probleme lösen können.

Zielpublikum: Software-Architekt:innen, Softwareentwickler:innen, Projektleiter:innen, Manager:innen
Voraussetzungen: Projekterfahrung
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract

Als Missverständnisse werde ich ansprechen:

1) Microservices bilden eine SOA

2) Überall Events

3) Jedes Team wie es will

4) Wiederverwendung

5) Gegen Zyklen helfen Interfaces

6) Sourcecode = Dokumentation

7) Neubau ist besser als Refactoring

Dabei erkläre ich das Missverständnis und biete jeweils eine oder mehrere entgegengesetzte Sichtweisen an. Beispiele benutze ich, um die Argumentation zu verdeutlichen, und schließlich gebe ich jeweils meine Empfehlung dazu.

Dr. Carola Lilienthal ist Geschäftsführerin bei der WPS - Workplace Solutions GmbH und Mitglied der Geschäftsleitung. Seit 1998 entwickelt sie qualitativ hochwertige Softwaresysteme mit ihren Teams. Carola hält regelmäßig Vorträge auf Konferenzen, schreibt Artikel und hat ein Buch zum Thema „Langlebige Software-Architekturen“ veröffentlicht.

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

Carola Lilienthal
Carola Lilienthal
flag VORTRAG MERKEN

Vortrag Teilen

, (Donnerstag, 03.Februar 2022)
14:30 - 15:30
Do 1.3
Events@Allianz
Events@Allianz

Der Beitrag diskutiert, wie man event-getriebene Architekturen als eine Form der reaktiven Architekturen in einer Beratungssoftware einsetzen kann. Warum wurde für diese Beratungssoftware der event-getriebene Ansatz gewählt? Es werden sowohl die geschäftlichen als auch die technischen Anforderungen diskutiert, die zur Wahl dieses Architektur-Ansatzes geführt haben. Der event-getriebene Ansatz erwies sich als der richtige, um eine Entkopplung der Systeme und ein gesamthaftes Bild der einzelnen Aktivitäten für den Benutzer sicherzustellen.

Zielpublikum: Architekt:innen, Entwickler:innen, Entscheider
Voraussetzungen: Prinzipielles Verständnis von Software-Architektur
Schwierigkeitsgrad: Anfänger

Extended Abstract
1. Vorstellung Beratungssoftware
2. Vorstellung Beratungsprozess
3. Variante als steuernder Prozess (klassische Architektur)
4. Variante als event-getriebener Prozess (reaktive Architektur)
5. Vorstellung der technischen Architektur
6. Vor- und Nachteile des gewählten Ansatzes
7. Weitere Arbeiten

Detail:
Die Beratungssoftware der Allianz Gruppe wird in den Agenturen eingesetzt, um Kunden gezielt und individuell beraten zu können. Dabei ist es wichtig, dem Berater auf der einen Seite Hilfe und Richtung in den teilweisen komplizierten Produkten anzubieten und auf der anderen Seite die notwendige Flexibilität des Verkaufsprozesses nicht einzuschränken.
Technisch erlauben Events, die Informationen von sehr unterschiedlichen Systemen ohne eine enge Kopplung dem Agenten zur Verfügung zu stellen. Der Gesamtprozess muss nicht den Einzelsystemen bekannt sein, sondern wird vielmehr aus den verschiedenen Informationen erst gebildet.
Dadurch erreicht man eine hoch flexible und entkoppelte Architektur, ohne auf Gesamtüberblick und strukturierte Darstellungen verzichten zu müssen.

Annegret Junker ist Lead Architect bei Allianz Deutschland. Sie arbeitet seit mehr als 30 Jahren in der Software-Entwicklung in unterschiedlichen Rollen und unterschiedlichen Domänen wie Automotive, Versicherungen und Finanzdienstleistungen. Besonders interessiert sie sich für DDD, Microservices und alles, was damit zusammenhängt. Derzeit arbeitet sie in einem großen Versicherungs-Projekt als übergreifende Architektin.

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

Annegret Junker
Annegret Junker
flag VORTRAG MERKEN

Vortrag Teilen

14:30 - 15:30
Do 5.3
Monolith To Microservices
Monolith To Microservices

Big Bang rebuilds of systems are so 20th century. With our users expecting new functionality to be shipped more frequently than ever before, we no longer have the luxury of a complete system rebuild. In fact, a big bang migration of a monolithic architecture into a microservice architecture can be especially problematic, as we’ll explore in this talk.

We want to ship features, but we also want to improve our architecture, and for many of us this means breaking down existing systems into microservices. But how do you do this while still regularly releasing new features?

In this talk, I’ll share with you some key principles and a number of patterns which you can use to incrementally decompose an existing system into microservices. I’ll also cover off patterns that can work to migrate functionality out of systems you can’t change, which are useful when working with very old systems or vendor products. We'll look at the use of strangler patterns, change data capture, database decomposition and more.

Coming out of this talk you’ll have a better understanding of the importance of evolving an architecture, along with some concrete patterns to help you do that on your own projects.

Target Audience: Developers, architects, operations, testers and anyone actively involved in software delivery
Prerequisites: Basic knowledge about microservices and software delivery
Level: Advanced

Sam is a technologist and consultant who focuses in the areas of cloud, continuous delivery and microservices. As well as helping companies all over the world get software into production, Sam is also an experienced conference speaker and writer. He is author of Building Microservices, 1st Edition (O’Reilly, 2015), Monolith To Microservices (O’Reilly, 2019), and Building Microservices, 2nd Edition (O’Reilly, 2021).
Sam Newman
Sam Newman
flag VORTRAG MERKEN

Vortrag Teilen

, (Freitag, 04.Februar 2022)
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 Schwentner loves programming in high quality. He lives this passion as coder, coach, and consultant at WPS – Workplace Solutions in Hamburg, Germany. There he helps teams to structure their monoliths or to build new systems from the beginning with a sustainable architecture. Microservices or self-contained systems are often the result. Henning is author of “Domain Storytelling – A Collaborative Modeling Method” and the www.LeasingNinja.io as well as translator of “Domain-Driven Design kompakt”.

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

Henning Schwentner
Henning Schwentner
flag VORTRAG MERKEN

Vortrag Teilen

Zurück