Konferenzprogramm

Thema: DDD / Anforderungen

Nach Tracks filtern
Nach Themen filtern
Alle ausklappen
  • Dienstag
    22.10.
  • Mittwoch
    23.10.
  • Donnerstag
    24.10.
, (Dienstag, 22.Oktober 2024)
10:10 - 10:55
Di2.1
How to Read Code (Properly)
How to Read Code (Properly)

Why are we always complaining about old code? Why are we rarely happy when digging into old stuff, especially old code by other people?

It is very tempting to believe that you can easily do it better than that. And that you can improve the situation by rewriting code. By making stuff simpler. In the first park of this talk, I will dive into why we believe this. Expect some insights into psychology and into how our brains work :)

Second part: Why we are wrong, most of the times. Again, this will be about psychology and biases, about code reading and about the IT as a business.

I'm Anja, Principal Fullstack Engineer working at Mister Spex @ Berlin, Germany. We are right now breaking down a monolith and replacing parts of it by future-ready technology. Previously, I have worked for eBay.
Also, I'm sports enthusiast and current local champion in wakeskating. I love to find and cross the borders of what seems achievable.

Anja Kunkel
10:10 - 12:15
Di3.1
Combining Event Storming and Hexagonal Architecture with Test-Driven Development
Combining Event Storming and Hexagonal Architecture with Test-Driven Development

This workshop utilises insights from a previous Event Storming session to design a well-structured hexagonal architecture for a software system. Clear and intuitive naming conventions are prioritized to ensure that the resulting design accurately reflects the intricacies of the domain. Test-Driven Development (TDD) principles are embraced to move seamlessly from concept to implementation, fostering a rigorous and iterative development process. By combining EventStorming, Hexagonal Architecture, and TDD, participants can understand how these methodologies work together to create robust software solutions.

Join us for 2–3 hours of learning and fun. Bring your notebook and have your development environment (IDE) ready to write tests and code!

Patrick Baumgartner works as a passionate software crafter, coach, and trainer at 42talents. He works with people to create beautiful and simple solutions and enjoys building software for the cloud with Java, the Spring ecosystem, Neo4j and ElasticSearch and other open-source technologies. 

Khaled is a versatile tech professional with experience in development, architecture, auditing, coaching, and team leadership. He has worked in Tunisia, France, Canada, and Switzerland for over a decade.

Patrick Baumgartner, Khaled Souf
Patrick Baumgartner, Khaled Souf

Vortrag Teilen

13:45 - 14:45
Di1.3
Domain-Driven Design: Ein vollständiges Beispiel
Domain-Driven Design: Ein vollständiges Beispiel

Was bedeutet es eigentlich, Domain-driven Design (DDD) umzusetzen? Dieser Vortrag führt durch ein vollständiges Beispiel und zeigt, wie verschiedene Techniken wie Event Storming, strategisches Design und taktisches Design zusammenwirken, um den Aufbau von Anwendungen zu unterstützen. Auf diese Weise bekommen die Teilnehmer praktische Hinweise, wie sie mit einem einfachen, aber vollständigen Ansatz mit DDD beginnen können.

Eberhard Wolff verfügt über mehr als 20 Jahre Erfahrung als Architekt und Berater – oft an der Schnittstelle von Wirtschaft und Technologie. Er ist Head of Architecture bei SWAGLab. Als Redner hat er auf internationalen Konferenzen Vorträge gehalten und als Autor hat er mehr als 100 Artikel und Bücher geschrieben, z.B. über Microservices und Continuous Delivery. Sein technologischer Fokus liegt auf modernen Architekturen – oft unter Einbeziehung von Cloud, Continuous Delivery, DevOps, Microservices oder NoSQL.

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

Eberhard Wolff
Eberhard Wolff

Vortrag Teilen

, (Mittwoch, 23.Oktober 2024)
13:45 - 14:45
Mi1.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

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:

  • Domain-Driven Design im Wasserfall
  • Ignoranz für Code (aka nur Fokus auf strategisches Design)
  • übermäßiger Gebrauch von Mustern um ihrer selbst willen
  • kulturelle Implikationen
  • Cargo-Kult
  • Developer Experience
  • eingeschränkte Verfügbarkeit von Fachexperten
  • Umgang mit etablierten Modellierungstechniken/Methoden
  • 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
Michael Plöd
Vortrag: Mi1.3

Vortrag Teilen

, (Donnerstag, 24.Oktober 2024)
09:00 - 17:00
Do3
Domain Driven API Design
Domain Driven API Design

Were you ever forced to use an API you don't understand? You hated more or less. Do you want to create APIs someone would love (or at least won't hate)?
The talk discusses those questions using a sample and using Domain Story Telling and Event Storming. Out of them, you will get nice APIs, which your developers won’t hate.

  1. Introducing a task management system with results out of a domain storytelling and event storming
  2. Context Map based on the Event Storming
  3. Hands on in groups: Discussion of the interfaces - asynchronous vs. synchronous
  4. Hands on in groups: Definition of the interfaces using OpenAPI and AsyncAPI
  5. Discussion of the interfaces

Dieser Workshop muss zusätzlich gebucht werden.

Annegret is an chief software architect at codecentric AG. She has worked in software development for over 30 years. She worked in quite different roles such as product owner, programmer and architect and quite different domains such as automotive and insurance. Especially is she interested in domain driven design, microservices and everything along with it. Especially, she takes care for good and nice APIs.

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

Annegret Junker
Annegret Junker

Vortrag Teilen

09:00 - 17:00
Do4
Domain-Driven Transformation—How to Bring (Back) Sustainable Architecture to Legacy and Monoliths
Domain-Driven Transformation—How to Bring (Back) Sustainable Architecture to Legacy and Monoliths

Today we know very well how to start a new project on a greenfield and how to build a good architecture. But most of us work in projects that have been around for a long time and whose architecture (to put it mildly) is not quite so beautiful. “Monolith” and “Big Ball of Mud” are the unflattering labels put on such systems.

This talk will show how we can introduce (or bring back) structure. Every system is different here, so it’s important to first understand where you are. Then the right steps have to be taken. I present a catalog of refactorings to choose from and heuristics which are the right choices.

The catalog contains refactorings that help to cure: BBOM architecture, anemic domain models, and badly organized teams.

Dr. Sönke Magnussen hat an der Christian-Albrechts-Universität in Kiel Diplom Informatik studiert und promovierte im Jahr 2003 an der Universität Lübeck im Bereich Software Engineering und Programmiersprachen. Nach der Promotion wechselte Sönke zur Lufthansa und arbeitete hier in verschiedenen Rollen (Softwareentwickler, IT-Architekt, Manager mit Führungsverantwortung) an der Wartung und Weiterentwicklung, an Architektur-Projekten und Betriebsthemen von größeren Softwaresystemen und Applikationslandschaften. 

Seiner großen Leidenschaft (Softwareentwicklung und IT-Architektur) bleibt Sönke auch nach einigen Ausflügen in die Prozess-Automatisierung mit Robotics-Process-Automation (RPA), AI, Natural Language Processing treu und bringt seinen reichhaltigen Erfahrungsschatz nun als IT-Architekt, IT-Consultant, Trainer und Projektleiter in Kundenprojekte der WPS ein. Der Fokus seiner Arbeit liegt in der Transformation von größeren Systemen/Landschaften und Organisationen mit dem Ziel, die Systeme zukunftsfähig für  die Digitalisierung oder andere große Herausforderungen aufzustellen. Meistens bedeutet dies eine Transformation hin zu modularen IT-Architekturen, Cloudtechnologie und DevOps, um damit eine agilere Anpassung von Software und einen flexibleren und sichereren Betrieb der IT-Systeme zu ermöglichen. Dabei bildet häufig Domain-Driven Design (DDD) das Fundament für die Erarbeitung einer angemessenen IT-Architektur sowie dem richtigen Aufbau der IT-Organisation.

Zurück