Immer mehr Softwareprojekte setzen auf eventgetriebene Architekturen, da sie einfache Erweiterbarkeit, Robustheit und Skalierbarkeit sowie lose Kopplung versprechen. Oft wird dabei jedoch die Komplexität der Implementierung unterschätzt. Diese ergibt sich nicht nur aus technischen Herausforderungen, die gelöst werden müssen, sondern auch daraus, dass viele unterschiedliche Vorstellungen davon existieren, was eine eventgetriebene Architektur eigentlich ist und wie sie zu funktionieren hat.

Diese unterschiedlichen Auffassungen können einerseits zu Problemen im Betrieb führen, andererseits kann ein wachsendes System neue Herausforderungen mit sich bringen, die man anfangs nicht berücksichtigt hat. Basierend auf unseren eigenen leidvollen Erfahrungen in Projekten und teils ähnlichen Erlebnissen unserer Kollegen haben wir eine Liste von Anti-Patterns identifiziert, die entweder aus unterschiedlichen Auffassungen und deren Umsetzung resultieren oder die durch Evolution des Systems die Entwicklung und den Betrieb eines solchen Systems erheblich erschweren können. In diesem Vortrag stellen wir diese Anti-Patterns vor, zeigen, welche Probleme sie verursachen und wie man sie vermeiden kann.

Architektur-Reviews finden zunehmend mehr Verbreitung und ergänzen die schon länger etablierten Code-Reviews. Das finden wir super, denn wir sind überzeugt davon, dass damit alle Entwicklungsprojekte ein sehr mächtiges Werkzeug an der Hand haben, um sich bei wichtigen Entscheidungen abzusichern oder um Probleme früh zu erkennen. Von ATAM über RATE bis zu LASR sind zahlreiche Methoden entstanden, um Architekturreviews strukturiert durchführen zu können. Aber die Methoden kennenzulernen ist nur ein erster Schritt, denn ein wesentlicher Erfolgsfaktor ist die Erfahrung aus anderen Architektur-Reviews.

Mit unserem Vortrag möchten wir euch den Start erleichtern. Wir berichten von unseren Erfahrungen aus mehr als 15 Jahren und über 75 Architektur-Reviews und machen diese auch für eure Reviews zugänglich. Wir zeigen, welches Vorgehen sich für welche Projektsituation und Aufgabestellung eignet, von leichtgewichtiger Absicherung bis Vorbereitung einer Systemmodernisierung. Wir greifen konkrete, wiederkehrende und herausfordernde Fragestellungen heraus und zeigen, wie ihr damit umgehen könnt und worauf ihr besser verzichtet. 

Außerdem plaudern wir aus dem Nähkästchen, denn bei Reviews mit Bewertungscharakter geht es auch mal kritischer zur Sache. Umso mehr heißt es dann einen kühlen Kopf zu bewahren, um mit dem Architektur-Review bleibenden Nutzen zu erzeugen.

Resilience is an important issue these days. Many companies claim to have a resilient IT, very few have one.

What does it mean to be resilient? How do I get there? How can I figure out where I currently am? How can I improve?

We will look at several gradations of becoming resilient. We will examine their properties and tradeoffs and how to get there. We will discuss what we can achieve at an IT system level and when we need to address the whole socio-technical system.

At the end of the session, we will have drawn a map from here to resilience you can use as a travel guide towards your resilient IT.

Single-Page-Anwendungen (SPA) sind einerseits weit verbreitet, andererseits aber auch umstritten. Sie bieten ein hohes Maß an Interaktivität und Komfort für Benutzer:innen, aber nicht für jede Anforderung ist eine SPA deswegen automatisch die richtige Wahl. Auf der anderen Seite wiederum sind "klassische" auf dem Server gerenderte Anwendungen oftmals nicht ausreichend, wenn es um Webanwendungen mit viel Interaktivität geht. Diese Lücke möchte die Bibliothek HTMX schließen, die serverseitiges Rendering mit einem beliebigen Backend ermöglicht. Im Frontend verspricht sie sowohl eine nahezu JavaScript-freie Entwicklung als auch feingranulare Aktualisierungen der Oberfläche, ähnlich wie von SPAs gewohnt. Ist HTMX also die perfekte Allzwecklösung fürs Frontend?

Anhand praktischer Beispiele möchte ich Single-Page-Anwendungen und HTMX gegenüberstellen. So werden wir sehen, wo die Stärken und Schwächen der beiden Ansätze liegen und für welche Anwendungen sie jeweils geeignet sind. 

Neben Beispielen mit Java und Spring werde ich ein paar React-Beispiele zeigen, die du aber auch ohne React-Vorkenntnisse verstehen wirst. Wenn du dich also für moderne Webentwicklung interessierst, bist du in diesem Vortrag genau richtig!

Vor zehn Jahren habe ich zum ersten Mal einen Vortrag über Event-driven Architecture gehalten. Kafka war gerade seit zwei Jahren Open Source und bei Version 0.8, und nur ein paar Wochen vorher war Java 8 erschienen, und die erste Version von Spring Boot. Damals war gerade das Label "reactive" populär, und so hieß er "From Enterprise To Reactive". Unter anderem habe ich das Saga-Pattern propagiert.

In den zehn Jahren habe ich einiges dazugelernt - musste aber vor allem auch vieles erst einmal verlernen. In diesem Vortrag ziehe ich eine kleine Bilanz: Welche Ansätze haben sich in den zehn Jahren bewährt, und welche waren für mich enttäuschend? (In welcher Kategorie wird wohl das Saga-Pattern wieder auftauchen?)

Nicht alles wird sich übertragen lassen, aber manche Einsicht kann vielleicht hilfreich sein.

Softwaresysteme bestehen aus Bausteinen. Aber kann ein Softwaresystem Baustein eines anderen sein? Andersherum: Besteht ein System aus "Bausteinen all the way down"? Das wäre gut, weil beim Zusammensetzen die Details verschwinden und so konsequent abstrahiert wird – wir komponieren dann, anstatt einfach nur zu basteln.  Das gleiche gilt für Domänenmodelle – sogennante Kombinatormodelle sind flexible Baukästen statt starrer Formulare.

Die Realität der meisten Systeme sieht leider anders aus: Softwaresysteme und ihre Bausteine werden mehr schlecht als recht miteinander verschaltet, bedingt auch durch gängige Architekturmuster wie die hexagonale Architektur, die einfach nicht komponieren. Bei den Domänenmodellen ist es ähnlich: Elemente typischer OO-Modelle lassen sich oft nur begrenzt zusammensetzen – in der obersten Schicht ist Schluss. Entsprechend groß ist der Refaktorisierungs- und Modernisierungsaufwand, wenn sich die Anforderungen ändern.

Im Talk gehen wir auf eine Reise der Kompositionalität auf verschiedenen Ebenen: Wir besuchen Projekte aus der Praxis, bei denen Kompositionalität ein zentrales Designprinzip ist, nahezu unbegrenzt flexible Kombinatormodelle und kompositionale Modulsysteme. Wir ziehen Paralleln zum Prinzip "closure of operations" im DDD und zeigen die Prinzipien, die du beim Einsatz von Komposition beachten solltest.

Code-Basen, die schwer zu ändern sind, leiden oft unter zwei großen Problemen: einer fehlenden Ausrichtung an Domänengrenzen und dem fehlenden Ausdruck architektonischer Ideen im Code. Um dieses kritische Problem anzugehen, greifen Entwickler auf Separation-of-Concerns-Architekturen wie Onion-, Clean- und Hexagonal-Architektur zurück. Diese Ansätze erzielen jedoch oft gemischte Ergebnisse, da sie sich hauptsächlich auf die Trennung von technischem und Business-Code konzentrieren, ohne die strukturellen Aspekte der Domäne zu berücksichtigen.

In dieser Präsentation diskutieren wir Strategien zur Übersetzung von architektonischen Ideen und Designpatterns in Code auf verschiedenen Abstraktionsebenen. Wir erkunden, wie verschiedene Frameworks und Bibliotheken im Java-Ökosystem diesen Prozess unterstützen, indem sie die im Code vorhandenen Metainformationen für eine strukturelle Überprüfung, Testbarkeit und das Generieren von Dokumentation nutzen.

Dieser Workshop muss zusätzlich gebucht werden.

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.

Max. Teilnehmendenzahl: 30
Es wird ein eigener Laptop benötigt.

Dieser Workshop muss zusätzlich gebucht werden.