Freitag, 16:47 Uhr. Ein Pull Request mit einem kritischen Fix landet auf dem Tisch. Und plötzlich diese leise Frage im Hinterkopf: „Machen wir das wirklich noch vor dem Wochenende?”

Release Anxiety ist erstaunlich verbreitet. Nicht weil Teams unfähig wären — sondern weil Prozesse es sind. Manuelle Checklisten, Nachtdeployments, halbautomatische Pipelines und Changelogs, die „irgendwie” entstehen, machen Releases zu kleinen Events. Dabei sollten sie Routine sein.

Daniel Schock auf der stackconf 2026

Auf der stackconf 2026 spricht unser Kollege Daniel Schock genau darüber: „End Release Anxiety: A Guide to Fully Automated Workflows with Semantic Release”.

Es geht nicht um Tool-Evangelismus, sondern um die Transformation eines subjektiven, nervösen Rituals in einen reproduzierbaren, automatisierten Workflow.

Themen der stackconf

Die stackconf bringt Expertinnen und Experten aus dem gesamten Cloud-native- und DevOps-Ökosystem zusammen. Die Themenlandschaft spiegelt die aktuellen Herausforderungen moderner Infrastruktur:

Veranstaltungsort und Termin

Die stackconf 2026 findet am 28. und 29. April im Studio Balan in München statt. atra ist als Sponsor dabei.

Daniel Schock

Senior Software Engineer

Daniel ist ein erfahrener Fullstack-Entwickler und DevOps-Spezialist mit einem klaren Schwerpunkt auf der Backend-Entwicklung mit Java und Kotlin. Seine Expertise wird durch praktische Erfahrung in der Frontend-Entwicklung mit Vue.js abgerundet. Er verfügt über umfassende Kenntnisse in der Konzeption von CI/CD-Pipelines sowie im Einsatz von Cloud-Technologien wie Kubernetes und AWS, die er erfolgreich in den Branchen Versicherung, Logistik und E-Commerce einsetzte. Daniel arbeitet bevorzugt in agilen Umgebungen und zeichnet sich durch seine analytische Denkweise und hohe Problemlösungskompetenz aus.

d.schock@atra.consulting    

Warum scheitern so viele gut gemeinte Change-Initiativen trotz exzellenter Methoden, Tools und Roadmaps?

Weil sie meist nur einen Teil des Systems adressieren: 

• Prozesse oder Menschen.
• Strukturen oder Kultur.

In der Realität wirken diese Aspekte jedoch immer gleichzeitig – und genau dort entstehen Reibung, Überlastung und Stillstand.

Veränderung scheitert selten an fehlender Kompetenz.
Sie scheitert daran, wie Arbeit organisiert ist, wie Entscheidungen zustande kommen, wie mit Abhängigkeiten umgegangen wird – und wie Teams mit Spannungen umgehen, die aus Komplexität ganz natürlich entstehen.

Integral Facilitation setzt genau an diesem Punkt an.

Worum es bei Integral Facilitation wirklich geht

Integral Facilitation ist kein neues Toolset und keine Ersatzmethode.
Es ist ein Arbeitsansatz, um Veränderung dort wirksam zu machen, wo sie tatsächlich entsteht: in der Zusammenarbeit realer Teams unter realen Bedingungen.

Im Kern macht Integral Facilitation sichtbar und bearbeitbar, was in Veränderungsprozessen ohnehin wirkt – aber selten bewusst gestaltet wird:

Innere Dimensionen
Wie Menschen denken, priorisieren, Sinn erkennen oder Widerstand entwickeln.

Äußere Dimensionen
Meetings, Entscheidungswege, Prozesse, Artefakte, konkrete Ergebnisse.

Individuelle Perspektiven
Verantwortung, Führung, Selbstorganisation, Rollenverständnis.

Kollektive Dynamiken
Teamkultur, unausgesprochene Regeln, Konfliktmuster, Zusammenarbeit über Schnittstellen hinweg.

Die Wirkung entsteht nicht durch zusätzliche Reflexion, sondern dadurch, dass diese Ebenen miteinander in Beziehung gesetzt werden. So entsteht kollektive Handlungsfähigkeit – auch unter Druck, auch bei widersprüchlichen Anforderungen.

Einordnung im Vergleich zu Beratung und Change

Integral Facilitation ist kein Ersatz dieser Ansätze, sondern ergänzt sie dort, wo Komplexität nicht mehr sauber zerlegt werden kann und Zusammenarbeit selbst zum entscheidenden Erfolgsfaktor wird.

Eine praktische Orientierung für deinen Arbeitsalltag

Wenn du in komplexen Situationen feststeckst, hilft es, bewusst aus unterschiedlichen Blickwinkeln auf die gleiche Situation zu schauen.

Nicht, um mehr zu analysieren – sondern um schneller zu erkennen, wo du wirklich ansetzen kannst.

Vier Perspektiven haben sich dabei als besonders hilfreich erwiesen:

Innere Sicht
Was nehmen Menschen gerade wahr?
Welche Erwartungen, Spannungen oder Überlastungen sind spürbar?

Äußere Sicht
Was passiert konkret im Arbeitsalltag?
Wie laufen Meetings, Entscheidungen und Abstimmungen tatsächlich ab?

Team-Logik
Welche unausgesprochenen Regeln prägen die Zusammenarbeit?
Was „funktioniert hier einfach so“, ohne dass es je vereinbart wurde?

System-Logik
Welche Strukturen wirken im Hintergrund?
Rollen, Abhängigkeiten, KPIs, Schnittstellen – was verstärkt das aktuelle Verhalten?

Der entscheidende Unterschied: Viele Ansätze bleiben auf einer dieser Ebenen stehen.
Hier geht es darum, sie bewusst zusammen zu betrachten.

Erst dadurch wird sichtbar, warum Probleme stabil bleiben – und wo Veränderung mit möglichst wenig Aufwand ansetzen kann.

Mini-Fallgeschichte aus der Praxis

Ein Team beschreibt seine Situation so:
„Wir springen ständig zwischen Themen und kommen nicht wirklich voran.“

• Innere Sicht: Gefühl von Überlastung und fehlender Klarheit
• Äußere Sicht: viele parallele Themen, häufige Unterbrechungen
• Team-Logik: „Alles ist wichtig“ – niemand priorisiert klar
• System-Logik: viele Stakeholder, ungefilterte Anforderungen von außen

Teamgröße: 12 Personen
Branche: Versicherungsumfeld
Kontext: international, Englisch als Arbeitssprache

Das Team verantwortet parallel:

• stabile Run- und Maintenance-Aufgaben
• kontinuierliche Weiterentwicklung
• akute Produktionsprobleme

Die fachlich stärksten Entwickler werden regelmäßig aus der Entwicklung gezogen, um Incidents zu lösen. Gleichzeitig gibt es viele Ansprechpartner, zahlreiche Abhängigkeiten und regelmäßige Einwürfe „von links“ – fachlich wie organisatorisch.

Der fachliche Kontext ist komplex, die Fluktuation vergleichsweise hoch, Einarbeitungszeiten sind lang. Durch die internationale Zusammenarbeit reduziert sich zudem die fachliche Tiefe in Diskussionen – nicht aus Unwillen, sondern aus pragmatischer Sprachökonomie.

Die Folgen im Alltag:

• Meetings werden zunehmend als Belastung erlebt
• Veränderung wird eher defensiv betrachtet
• Gute Ideen bleiben liegen, weil Zeit und Fokus fehlen
• Einzelne Schlüsselpersonen tragen einen Großteil des Produktionsdrucks

Der entscheidende Punkt ist:

Das Problem liegt nicht nur in der Planung – sondern im Zusammenspiel der genannten Ebenen und Perspektiven. Deshalb setzten wir nicht bei neuen Prozessen an, sondern bei der Art der Zusammenarbeit.

Wie konkret angesetzt wurde

Produktionsarbeit genutzt, um Last zu verteilen und Kompetenz aufzubauen
Produktionsprobleme bleiben Priorität – aber nicht mehr Aufgabe einzelner Schlüsselpersonen. Mehr Entwickler wurden gezielt in Analyse und Lösungsfindung eingebunden – nicht nur zur Entlastung, sondern als bewusster Teil des Kompetenzaufbaus.

Priorisierung im Moment geklärt – auch gegenüber Stakeholdern
Backlog und Struktur waren vorhanden. Entscheidend war, Priorisierung im Alltag bewusst zu machen. Neue oder eskalierende Themen wurden aktiv rückgekoppelt: Was bedeutet diese neue Priorität konkret – und was wird dafür verschoben?
Diese Klärung wurde auch gegenüber Stakeholdern eingefordert.

Schnittstellen klarer statt schneller gemacht
Bei vielen Abhängigkeiten wurde nicht versucht, alles sofort zu klären.
Stattdessen wurde bewusst unterschieden: Was gehört in unseren Verantwortungsbereich – und was nicht?
Dabei ging es nicht um Abgrenzung, um der Abgrenzung willen, sondern um ein klareres, verlässlicheres Zusammenspiel.

Fokuszeiten aktiv geschützt
Fokus wurde nicht dem Zufall überlassen, sondern bewusst gestaltet.
Es wurde klarer vereinbart, wann Abstimmung notwendig ist – und wann konzentriertes Arbeiten Vorrang hat.

Was sich dadurch verändert hat

• Produktionsdruck verteilt sich auf mehrere Schultern
• Prioritäten werden bewusster entschieden statt implizit gelebt
• Schnittstellen verursachen weniger Reibung
• Wissen wächst im Team statt bei Einzelnen
• Fokuszeiten werden wirksam – nicht nur geplant

Das Ergebnis:

• weniger Kontextwechsel
• spürbar weniger Frustration
• bessere Planbarkeit trotz gleichbleibender Komplexität

Die Fragen, die uns geholfen haben und die Du gleich in Deinem Team stellen könntest, um ähnliche Ergebnisse erzielen, sind die folgenden:

Fragen, die Wirkung freilegen

• Wo optimieren wir Symptome, statt Zusammenarbeit zu gestalten?
• Welche Probleme tauchen immer wieder auf – unabhängig vom Toolset?
• Welche Spannungen sind systemisch – und welche machen wir unnötig persönlich?
• Wo liegt der kleinste Hebel mit der größten Wirkung?

Veränderung beginnt dort, wo Zusammenarbeit bewusst gestaltet wird

Integral Facilitation ist keine Technik, die man einführt. Es ist eine Haltung zur Gestaltung von Zusammenarbeit in komplexen Umfeldern – und die Bereitschaft, mehrschichtig zu denken und zu handeln.

Spannungen, Widerstände und Reibung werden dabei nicht als Störung gesehen, sondern als Hinweis darauf, wo Entwicklung möglich ist.

Vielleicht ist der nächste Schritt kein neues Tool oder eine bessere KI.
Vielleicht ist es ein anderes Gespräch im Team. Oder der Mut, eine der Fragen aus diesem Artikel gemeinsam anzugehen.

Nicht, um schneller oder effizienter zu werden. Sondern um wirksamer  zusammenzuarbeiten.

Dort beginnt Veränderung, die den Kern der Herausforderungen adressiert und nachhaltig wirkt.

Was wäre möglich, wenn Du das in deinem Umfeld einfach einmal ausprobierst?

Johannes Uske

Agile Master

Johannes ist ein erfahrener Agile Coach. Er bringt umfassende Erfahrungen in Transformationen, Scrum, SAFe und Teamentwicklung in den Bereichen IT, Konsumgüter, Banking und Automobil mit. Sein Fokus liegt auf praxisnahen Trainings, Führungskräfte-Coaching und systemischer Beratung, die nachhaltige Veränderungen und Selbstorganisation fördern. Durch den Einsatz partizipativer Methoden beseitigt er Blockaden und steigert den Teamerfolg. Johannes legt besonderen Wert auf psychologische Sicherheit, Produktqualität, Kundenzufriedenheit, Wertschätzung und kontinuierliche Verbesserung – und stärkt so Teams, um ihre Kollaboration zu optimieren.

j.uske@atra.consulting    

Dieser Moment war ein klassischer Reality-Check. Er markiert den Punkt, an dem wir erkennen müssen: Die Kernkompetenz im Software Engineering verschiebt sich unwiderruflich von der Implementierung zur Verifikation. In einer Welt, in der wir zehnmal mehr Code produzieren können, müssen wir hundertmal besser darin werden, diesen zu prüfen. Qualitätssicherung rückt vom Ende der Kette direkt in das Zentrum der strategischen Wertschöpfung.

Die Psychologie des Scheiterns: Drei neue Anti-Patterns

Wir müssen ehrlich sein: Wenn eine KI in Sekunden eine Lösung generiert, die syntaktisch brillant aussieht, schaltet unser Hirn in den Energiesparmodus. Wir verfallen in Verhaltensmuster, die im Enterprise-Umfeld fatale Folgen haben:

1. Der Rubber-Stamp-Reviewer: Man ertappt sich bei dem Gedanken: „Der Code sieht sauberer aus als das, was ich in einer Stunde mühsam händisch tippen würde.“ Man klickt auf Approve, ohne die logische Tiefe wirklich durchdrungen zu haben. Es ist eine Mischung aus falscher Bescheidenheit gegenüber der KI und schlichter Review-Fatigue.
2. Die Illusion der Unit-Test-Abdeckung: Es ist verlockend, die KI den Code und die passenden Tests schreiben zu lassen. Doch das ist ein gefährlicher Zirkelschluss. Die KI beweist lediglich, dass ihr Code das tut, was sie glaubt, dass er tun soll. Die tatsächliche Business-Logik bleibt oft unvalidiert im Schatten.
3. Die Gefahr der Kontext-Blindheit: KIs verstehen das „Was“, aber oft nur dann das „Warum“, wenn wir es ihnen explizit vorgeben. Wer sich blind auf generierte Lösungen verlässt, ohne architektonische Leitplanken zu setzen, importiert technologische Schulden in Rekordtempo. Die KI ist nicht per se „unwissend“ über Architektur – sie ist nur so gut wie der Kontext, den wir ihr zur Verfügung stellen.

Die strategische Konsequenz: Der Entwickler als Kurator

Diese Verschiebung hat massive Auswirkungen auf die Organisation von IT-Teams. Wenn Code zur Commodity wird, ändert sich das Anforderungsprofil:

• Seniorität durch Validierungskompetenz: Die Fähigkeit, Code zu schreiben, reicht nicht mehr aus. Ein Senior-Entwickler muss heute primär ein Senior-Validierer sein. Er braucht ein tieferes Verständnis für Softwarearchitektur und Security, um die subtilen Halluzinationen der KI im System-Kontext zu erkennen.
• Die Junior-Lücke: Wir laufen Gefahr, eine Generation von Entwicklern zu verlieren, die das „Handwerk“ nicht mehr von der Pike auf lernt. Unternehmen müssen hier aktiv mit Mentoring-Modellen gegensteuern, die den Fokus auf das „Lesen und Verstehen“ von Systemen legen.

Der neue Audit-Cycle: Vier Säulen der Qualität

Um die Geschwindigkeit des Vibe-Codings sicher zu beherrschen, brauchen wir eine klare Struktur. Es geht nicht um die Verlangsamung des Prozesses, sondern um seine Absicherung.

1. Automatisierte Leitplanken (Hard Gates)

Maschineller Code braucht maschinelle Kontrolle. SAST-Tools, Secrets Scanning und Architecture-Unit-Tests (wie ArchUnit) müssen jeden Commit scannen. Diese Tools fangen die „stochastischen Ausreißer“ ab, die LLMs prinzipbedingt immer wieder produzieren.

2. Die Renaissance der Dokumentation (Contextual Excellence)

Damit die KI nicht halluziniert, braucht sie erstklassigen Input. Wir erleben gerade, dass „alte“ Tugenden wie präzise PRDs (Product Requirement Documents) oder ADRs (Architecture Decision Records) zum kritischen Erfolgsfaktor werden. Tools wie Claude Code oder Cursor nutzen spezifische Konfigurationsdateien (z. B. CLAUDE.md oder .cursorrules), um Architektur-Leitplanken maschinenlesbar zu machen. Wer sauber dokumentiert, generiert sauberer.

3. Agenten testen Agenten (Cross-Model Validation)

Ein technisches Highlight ist der Einsatz spezialisierter Agenten-Kaskaden. Nutzen Sie die Konkurrenz der Modelle: Lassen Sie einen Architektur-Agenten die Einhaltung der Patterns überwachen und ein unabhängiges Review-LLM (z. B. Claude 3.5 Sonnet prüft GPT-4o-Output) nach logischen Fehlern suchen. Diese „Peer-AI“ deckt Blind Spots auf, die das ursprüngliche Modell systemisch übersieht.

4. Die menschliche Kuration (Der finale Filter)

Am Ende bleibt der Mensch als Architekt und Kurator unersetzlich. Seine Aufgabe ist die integrale Passfähigkeit: Entspricht die Lösung unseren langfristigen Wartbarkeits-Zielen? Ist die kognitive Last für das Team noch tragbar? Der Mensch unterschreibt nicht mehr für die Zeile Code, sondern für die Sinnhaftigkeit der Lösung im Gesamtgefüge.

Fazit: Skalierung der Verantwortung

KI beschleunigt nicht nur unsere Entwicklung – sie skaliert auch unsere Fehler. Wer glaubt, durch generative Tools QA-Ressourcen einsparen zu können, begeht einen strategischen Irrtum. Wir müssen die freiwerdende Zeit bei der Implementierung konsequent in die Vorbereitung (Kontext) und die Verifikation (Audit) investieren.

Professionalität im Jahr 2026 bedeutet: Wir nutzen den „Vibe“ für die Geschwindigkeit, aber wir bauen auf einer glasklaren Dokumentation und harten Architektur-Kompetenz für die Stabilität. Wer die Verifikation vernachlässigt, baut kein System, sondern ein Kartenhaus auf Steroiden.

Die Frage ist nicht, wie schnell Ihre Agenten heute coden können – sondern wie präzise Ihre architektonischen Leitplanken sind, die sie daran hindern, in die falsche Richtung zu rennen.

Meta-Hinweis: Dieser Text ist ein Experiment in eigener Sache. Er wurde vollständig generativ erstellt, wobei Few-Shot-Learnings meiner bisherigen Publikationen genutzt wurden, um meinen persönlichen Stil so authentisch wie möglich abzubilden. Während die Inhalte auf unserer realen Projekterfahrung bei atra.consulting basieren, fungierten wir – passend zur Kernthese des Artikels – als menschliche Kuratoren für die finale Validierung.

Daniel Wochnik

Geschäftsbereichsleitung »Finanzdienstleistungen«

Daniel ist seit 2017 in der IT-Branche aktiv und bringt seine umfassende Erfahrung als Senior Managing Consultant und Geschäftsbereichsleiter für Finanzdienstleistungen bei atra.consulting ein. Besonders begeistert ihn das Zusammenspiel technischer, methodischer und organisatorischer Aspekte. Als leidenschaftlicher Läufer und bekennender 1. FC Köln-Fan hat er seine Leidensfähigkeit auch privat mehrfach unter Beweis gestellt. Seine Kunden unterstützt er als Softwarearchitekt, agiler Coach und Berater bei der nachhaltigen und zielgerichteten Umsetzung von Entwicklungsprojekten.

d.wochnik@atra.consulting    

• LinkedIn

In der modernen Softwareentwicklung wird häufig mit monolithischen Strukturen begonnen, um schnell sichtbare Ergebnisse zu erzielen. Startpunkt ist oft ein einfaches Spring Boot Projekt, generiert über Initializer wie start.spring.io. Mit zunehmender Komplexität und wachsenden Anforderungen stoßen diese Strukturen jedoch an ihre Grenzen: Die Wartbarkeit sinkt, die Testbarkeit wird erschwert und technische Abhängigkeiten vermischen sich untrennbar mit der fachlichen Logik.

Eine Lösung für diese Herausforderungen bietet die hexagonale Architektur (auch bekannt als „Ports and Adapters“). Durch sie wird die Geschäftslogik ins Zentrum der Anwendung gerückt und von äußeren Einflüssen wie Datenbanken, Benutzeroberflächen oder externen APIs isoliert.

Dieser Artikel beschreibt die schrittweise Migration eines klassischen Spring Boot Monolithen hin zu einer modularisierten, hexagonalen Architektur unter Verwendung von Kotlin und Gradle. Es wird aufgezeigt, wie durch klare Modulgrenzen und definiertes Dependency Management eine langlebige und flexible Software-Architektur entsteht.

Zur besseren Nachvollziehbarkeit lassen sich die einzelnen Abschnitte Commit für Commit im GitHub-Repository nachvollziehen, der Zustand nach jedem Kapitel ist mit einem Git-Tag markiert.

Kapitel 0: Der Start

Als Ausgangszustand dient ein frisch generiertes Projekt von start.spring.io, welches das typische „Vorher“-Bild einer Anwendung darstellt.

1. Es wird zu start.spring.io navigiert.
2. Folgende Konfiguration wird ausgewählt:
   • Project: Gradle – Kotlin
   • Language: Kotlin
   • Spring Boot: (eine aktuelle Version, z.B. 3.5.x)
   • Java: 21
   • Dependencies:
     • Spring Web
     • Spring Data JPA
     • H2 Database
     • Spring Boot DevTools (optional)
     • Spring Configuration Processor (optional)
3. Das Projekt wird generiert, heruntergeladen und in der IDE geöffnet.

Es zeigt sich die typische, flache Spring-Boot-Struktur: Alle Komponenten befinden sich in src/main/kotlin unter einem Hauptpaket.

Diese Struktur eignet sich ideal für einen schnellen Start. Nachteile werden jedoch sichtbar, sobald das Projekt wächst:

• Keine Trennung von Belangen: Web-Logik (Controller), Business-Logik (Services) und Datenbank-Logik (Repositories, Entities) sind eng miteinander verwoben.
• Schwere Testbarkeit: Das Testen echter Business-Logik ohne das Hochfahren des Webservers oder das Mocken einer Datenbank gestaltet sich kompliziert.
• Technologie-Kopplung: Die Business-Logik ist untrennbar mit Spring-Annotationen (@Service, @Entity) und JPA verbunden.

Kapitel 1: Der Monolith

Um eine Refactoring-Basis zu schaffen, wird zunächst eine funktionierende, wenn auch architektonisch einfach strukturierte Anwendung aufgebaut. Als Beispiel dient ein simples „Produkt“, welches wir über REST-API in einer Datenbank ansprechen können. Folgendes Diagramm veranschaulicht die Zielsetzung.

classDiagram
    direction RL
    class Product {
        <<Entity / data class>>
        +Long? id
        +String name
        +Double price
    }
    class ProductsRepository {
        <<interface>>
    }
    class ProductsController {
        <<RestController>>
        -ProductsRepository repository
        +list() List~Product~
        +create(Product product) Product
        +get(Long id) Product?
        +update(Long id, Double discount) Product?
    }
    ProductsRepository ..> Product : manages
    ProductsController --> ProductsRepository : repository
    ProductsController ..> Product : uses

classDiagram
    direction RL
    class Product {
        <<Entity / data class>>
        +Long? id
        +String name
        +Double price
    }
    class ProductsRepository {
        <<interface>>
    }
    class ProductsController {
        <<RestController>>
        -ProductsRepository repository
        +list() List~Product~
        +create(Product product) Product
        +get(Long id) Product?
        +update(Long id, Double discount) Product?
    }
    ProductsRepository ..> Product : manages
    ProductsController --> ProductsRepository : repository
    ProductsController ..> Product : uses

Zuerst wird die Product.kt Klasse erstellt. Sie fungiert gleichzeitig als @Entity und data class – eine Klasse, die sämtliche Verantwortlichkeiten bündelt:

// src/main/kotlin/consulting/atra/hexagon/Product.kts

package consulting.atra.hexagon  
import jakarta.persistence.Entity  
import jakarta.persistence.GeneratedValue  
import jakarta.persistence.Id  

@Entity  
data class Product(  
    @Id  
    @GeneratedValue
    var id: Long? = null,  
    var name: String,  
    var price: Double,
)

// src/main/kotlin/consulting/atra/hexagon/Product.kts

package consulting.atra.hexagon  
import jakarta.persistence.Entity  
import jakarta.persistence.GeneratedValue  
import jakarta.persistence.Id  

@Entity  
data class Product(  
    @Id  
    @GeneratedValue
    var id: Long? = null,  
    var name: String,  
    var price: Double,
)

Als Nächstes folgt das ProductsRepository.kt, definiert als einfaches Spring Data JpaRepository:

// src/main/kotlin/consulting/atra/hexagon/ProductsRepository.kt

package consulting.atra.hexagon  
import org.springframework.data.jpa.repository.JpaRepository  
interface ProductsRepository: JpaRepository<Product, Long>

// src/main/kotlin/consulting/atra/hexagon/ProductsRepository.kt

package consulting.atra.hexagon  
import org.springframework.data.jpa.repository.JpaRepository  
interface ProductsRepository: JpaRepository<Product, Long>

Zuletzt wird der ProductsController.kt implementiert. Dieser @RestController injiziert das ProductsRepository direkt und verwendet das Product-Entity sowohl als Request- als auch als Response-Objekt:

// src/main/kotlin/consulting/atra/hexagon/ProductsController.kt
package consulting.atra.hexagon  
import org.springframework.web.bind.annotation.GetMapping  
import org.springframework.web.bind.annotation.PatchMapping  
import org.springframework.web.bind.annotation.PathVariable  
import org.springframework.web.bind.annotation.PostMapping  
import org.springframework.web.bind.annotation.RequestBody  
import org.springframework.web.bind.annotation.RequestMapping  
import org.springframework.web.bind.annotation.RequestParam  
import org.springframework.web.bind.annotation.RestController  
@RestController  
@RequestMapping("/api/v1/products")  
class ProductsController(  
    private val repository: ProductsRepository,  
) {  
    @GetMapping  
    fun list(): List<Product> = repository.findAll()  
    @PostMapping  
    fun create(@RequestBody product: Product): Product =
repository.save(product)  
    @GetMapping("/{id}")  
    fun get(@PathVariable id: Long): Product? =
repository.findById(id).orElse(null)  
    @PatchMapping("/{id}")  
    fun update(@PathVariable id: Long, @RequestParam discount: Double): Product? {  
        var product = repository.findById(id).orElse(null)  
        if (product != null) {  
            product.price *= (1 - discount / 100)  
            product = repository.save(product)  
        }  
        return product  
    }  
}

// src/main/kotlin/consulting/atra/hexagon/ProductsController.kt
package consulting.atra.hexagon  
import org.springframework.web.bind.annotation.GetMapping  
import org.springframework.web.bind.annotation.PatchMapping  
import org.springframework.web.bind.annotation.PathVariable  
import org.springframework.web.bind.annotation.PostMapping  
import org.springframework.web.bind.annotation.RequestBody  
import org.springframework.web.bind.annotation.RequestMapping  
import org.springframework.web.bind.annotation.RequestParam  
import org.springframework.web.bind.annotation.RestController  
@RestController  
@RequestMapping("/api/v1/products")  
class ProductsController(  
    private val repository: ProductsRepository,  
) {  
    @GetMapping  
    fun list(): List<Product> = repository.findAll()  
    @PostMapping  
    fun create(@RequestBody product: Product): Product =
repository.save(product)  
    @GetMapping("/{id}")  
    fun get(@PathVariable id: Long): Product? =
repository.findById(id).orElse(null)  
    @PatchMapping("/{id}")  
    fun update(@PathVariable id: Long, @RequestParam discount: Double): Product? {  
        var product = repository.findById(id).orElse(null)  
        if (product != null) {  
            product.price *= (1 - discount / 100)  
            product = repository.save(product)  
        }  
        return product  
    }  
}

Wird die Anwendung gestartet und die API aufgerufen, ist die Funktionalität gegeben.

Das Problem hierbei ist jedoch ersichtlich: Der Controller gibt die Datenbank-Entität (Product) direkt an den Client weiter. Jede Änderung an der Datenbankstruktur (z.B. das Hinzufügen einer internen Spalte) stellt sofort einen „Breaking Change“ für die API dar. Die API ist somit ein direktes Abbild der Datenbank.

Kapitel 2: Die neue Struktur

graph TD
    direction TB
    Application[":application"]
    Domain[":domain"]
    Endpoint[":adapters:endpoint"]
    Persistence[":adapters:persistence"]
    Application --> Domain
    Application --> Endpoint
    Application --> Persistence
    Endpoint --> Domain
    Persistence --> Domain

graph TD
    direction TB
    Application[":application"]
    Domain[":domain"]
    Endpoint[":adapters:endpoint"]
    Persistence[":adapters:persistence"]
    Application --> Domain
    Application --> Endpoint
    Application --> Persistence
    Endpoint --> Domain
    Persistence --> Domain

Nun wird das Fundament für die logische Trennung gelegt. Das einfache Projekt wird in ein Multi-Modul-Projekt umgewandelt.

Die Idee ist es, die Geschäftslogik, die eingehende und die ausgehende Kommunikation des Monolithen zu trennen und in einzelne Gradle-Module zu verlagern. Folgende Dateistruktur dient als Zielbild der Umstrukturierung:

.
├── adapters
│   ├── endpoint
│   │   └── build.gradle.kts
│   └── persistence
│       └── build.gradle.kts
├── application
│   ├── src
│   └── build.gradle.kts
├── domain
│   ├── src
│   └── build.gradle.kts
├── gradle
│   ├── wrapper
│   │   ├── gradle-wrapper.jar
│   │   └── gradle-wrapper.properties
│   └── libs.versions.toml
├── build.gradle.kts
├── CHANGELOG.md
├── CONTRIBUTING.md 
├── .editorconfig
├── .gitattributes
├── .gitignore
├── gradle.properties
├── gradlew
├── gradlew.bat
├── LICENSE
├── README.md
└── settings.gradle.kts

.
├── adapters
│   ├── endpoint
│   │   └── build.gradle.kts
│   └── persistence
│       └── build.gradle.kts
├── application
│   ├── src
│   └── build.gradle.kts
├── domain
│   ├── src
│   └── build.gradle.kts
├── gradle
│   ├── wrapper
│   │   ├── gradle-wrapper.jar
│   │   └── gradle-wrapper.properties
│   └── libs.versions.toml
├── build.gradle.kts
├── CHANGELOG.md
├── CONTRIBUTING.md 
├── .editorconfig
├── .gitattributes
├── .gitignore
├── gradle.properties
├── gradlew
├── gradlew.bat
├── LICENSE
├── README.md
└── settings.gradle.kts

Damit die Migrationsgrundlage erhalten bleibt, wird der src-Ordner zunächst in den zuvor erstellten application-Ordner verschoben.

Kapitel 2.1: settings.gradle.kts

Die settings.gradle.kts erfordert nun Aufmerksamkeit, da hier die Module definiert und die Grundlage eines zentralen Plugin- und Dependency-Managements geschaffen wird. Bisher war lediglich der Projektname hinterlegt.

rootProject.name = "hexagon"

// ...

rootProject.name = "hexagon"

// ...

Es wird ein pluginManagement-Block für die zentral definierte Plugin-Auflösung ergänzt:

// ...

pluginManagement {  
    repositories {  
        gradlePluginPortal()  
    }  
}

// ...

// ...

pluginManagement {  
    repositories {  
        gradlePluginPortal()  
    }  
}

// ...

Die Auflösung der Dependencies wird durch den dependencyResolutionManagement-Block gesteuert. Das Überschreiben der Repositories durch Module kann verhindert werden, indem der RepositoriesMode auf FAIL_ON_PROJECT_REPOS gesetzt wird. Da Gradle bei der Nutzung von repositories und repositoriesMode.set(RepositoriesMode.FAIL_ON_PROJECT_REPOS) im dependencyResolutionManagement-Block eine Warnung bezüglich UnstableApiUsage ausgibt, wird diese mit @Suppress(„UnstableApiUsage“) bewusst unterdrückt.

// ...

@Suppress("UnstableApiUsage")  
dependencyResolutionManagement {  
    repositoriesMode.set(RepositoriesMode.FAIL_ON_PROJECT_REPOS)  
    repositories {  
        mavenCentral()  
    }  
}

// ...

// ...

@Suppress("UnstableApiUsage")  
dependencyResolutionManagement {  
    repositoriesMode.set(RepositoriesMode.FAIL_ON_PROJECT_REPOS)  
    repositories {  
        mavenCentral()  
    }  
}

// ...

Mit einem include-Statement wird die settings.gradle.kts für ein modulares Gradle-Projekt vorbereitet. Hier werden die Module hinterlegt, wobei es für Gradle zu diesem Zeitpunkt unerheblich ist, ob die Ordner bereits existieren oder dazugehörige build.gradle.kts-Dateien enthalten sind.

// ...
include(  
    ":application",  
    ":domain",  
    ":adapters:endpoint",  
    ":adapters:persistence",  
)

// ...
include(  
    ":application",  
    ":domain",  
    ":adapters:endpoint",  
    ":adapters:persistence",  
)

Die fertige settings.gradle.kts stellt sich damit wie folgt dar:

// settings.gradle.kts

rootProject.name = "hexagon"  

pluginManagement {  
    repositories {  
        gradlePluginPortal()  
    }  
}  

@Suppress("UnstableApiUsage")  
dependencyResolutionManagement {  
    repositoriesMode.set(RepositoriesMode.FAIL_ON_PROJECT_REPOS)  
    repositories {  
        mavenCentral()  
    }  
}  

include(  
    ":application",  
    ":domain",  
    ":adapters:endpoint",  
    ":adapters:persistence",  
)

// settings.gradle.kts

rootProject.name = "hexagon"  

pluginManagement {  
    repositories {  
        gradlePluginPortal()  
    }  
}  

@Suppress("UnstableApiUsage")  
dependencyResolutionManagement {  
    repositoriesMode.set(RepositoriesMode.FAIL_ON_PROJECT_REPOS)  
    repositories {  
        mavenCentral()  
    }  
}  

include(  
    ":application",  
    ":domain",  
    ":adapters:endpoint",  
    ":adapters:persistence",  
)

Kapitel 2.2: build.gradle.kts

Das Herzstück der modularen Konfiguration bildet die build.gradle.kts. Hier werden projektweit gemeinsame Abhängigkeiten definiert und Gradle-Plugins konfiguriert.

Um die Versionen der verwendeten Gradle-Plugins zentral zu steuern, werden diese mit Versionsnummer projektweit in der build.gradle.kts definiert, die Verwendung jedoch gleichzeitig mit einem apply false verhindert. Dies ist notwendig, da Gradle die Plugins sonst im rootProject hinterlegen und ausführen würde. Da unterschiedliche Module unterschiedliche Konfigurationen benötigen, muss gezielt kontrolliert werden, welches Modul welches Plugin erhält.

plugins {  
    kotlin("jvm") version "1.9.25" apply false  
    kotlin("plugin.spring") version "1.9.25" apply false  
    id("org.springframework.boot") version "3.5.7" apply false  
    id("io.spring.dependency-management") version "1.1.7" apply false  
    kotlin("plugin.jpa") version "1.9.25" apply false  
}
// ...

plugins {  
    kotlin("jvm") version "1.9.25" apply false  
    kotlin("plugin.spring") version "1.9.25" apply false  
    id("org.springframework.boot") version "3.5.7" apply false  
    id("io.spring.dependency-management") version "1.1.7" apply false  
    kotlin("plugin.jpa") version "1.9.25" apply false  
}
// ...

Um gemeinsame Konfigurationen auf die Module anzuwenden, bietet Gradle unter anderem die Blöcke allprojects und subprojects an. allprojects konfiguriert alle Module, darunter auch das rootProject, während subprojects nur die untergeordneten Module betrifft. Für allprojects werden lediglich group und version gesetzt.

// ...
allprojects {  
    group = "consulting.atra.hexagon"  
    version = "0.0.0"  
}
// ...

// ...
allprojects {  
    group = "consulting.atra.hexagon"  
    version = "0.0.0"  
}
// ...

Für weitere grundlegende Modul-Konfigurationen wird der subprojects-Block verwendet. Hier werden unter anderem die Compiler-Settings, die Java-Version und Dependencies festgelegt. Zuerst werden die Plugins geladen, die das Grund-Setup der Module benötigt.

• java-library schaltet grundsätzliche Java-Compiler-Features frei; so kann die Java-Version erst mit diesem Plugin gesetzt werden. Darüber hinaus können mit dem Plugin kompatible Abhängigkeiten unter den einzelnen Modulen erreicht werden.
• org.jetbrains.kotlin.jvm stellt den Kotlin-Compiler bereit und ermöglicht dadurch die Verwendung von Kotlin in der JVM.
• org.springframework.boot bietet viele Funktionen rund um das Spring-Boot-Framework; vom Starten der Anwendung bis hin zum Bauen eines Images steht alles mit diesem Plugin zur Verfügung.
• org.jetbrains.kotlin.plugin.spring erweitert den Kotlin-Compiler um benötigte spring boot Features.
• io.spring.dependency-management wird für die Abhängigkeitsverwaltung verwendet. Im nächsten Kapitel wird dieses Plugin durch ein Gradle-eigenes Feature ersetzt.

// ...

subprojects {
    apply {  
        plugin("java-library")  
        plugin("org.jetbrains.kotlin.jvm")  
        plugin("org.springframework.boot")  
        plugin("org.jetbrains.kotlin.plugin.spring") 
        plugin("org.jetbrains.kotlin.plugin.jpa") 
        plugin("io.spring.dependency-management")  
    }

    // ...
}

// ...

subprojects {
    apply {  
        plugin("java-library")  
        plugin("org.jetbrains.kotlin.jvm")  
        plugin("org.springframework.boot")  
        plugin("org.jetbrains.kotlin.plugin.spring") 
        plugin("org.jetbrains.kotlin.plugin.jpa") 
        plugin("io.spring.dependency-management")  
    }

    // ...
}

Bevor Abhängigkeiten definiert werden, verlangt Spring Boot das Erweitern der DependencyConfiguration compileOnly von annotationProcessor. DependencyConfigurations sind ClassPath-Container, in denen kompilierte Artefakte hinterlegt sind. Dadurch können Abhängigkeiten für einzelne Zwecke selektiv verwendet werden. So ist es beispielsweise möglich, für Tests andere Bibliotheken zu nutzen als für die eigentliche Implementierung, oder Bibliotheken nur während der RunTime zu verwenden, die zum Kompilieren nicht benötigt werden.

// ...

subprojects {
    // ...
    val annotationProcessor by configurations  
    val compileOnly by configurations  
    val implementation by configurations  
    val testImplementation by configurations  
    val testRuntimeOnly by configurations  

    configurations {  
        compileOnly.extendsFrom(annotationProcessor)  
    }  

    dependencies {  
        implementation("org.jetbrains.kotlin:kotlin-reflect")
        testImplementation("org.springframework.boot:spring-boot-starter-test")  
        testImplementation("org.jetbrains.kotlin:kotlin-test-junit5")  
        testRuntimeOnly("org.junit.platform:junit-platform-launcher")  
    }

    // ...
}

// ...

subprojects {
    // ...
    val annotationProcessor by configurations  
    val compileOnly by configurations  
    val implementation by configurations  
    val testImplementation by configurations  
    val testRuntimeOnly by configurations  

    configurations {  
        compileOnly.extendsFrom(annotationProcessor)  
    }  

    dependencies {  
        implementation("org.jetbrains.kotlin:kotlin-reflect")
        testImplementation("org.springframework.boot:spring-boot-starter-test")  
        testImplementation("org.jetbrains.kotlin:kotlin-test-junit5")  
        testRuntimeOnly("org.junit.platform:junit-platform-launcher")  
    }

    // ...
}

Anschließend werden die Extensions konfiguriert. Gradle erlaubt es, die DSL über Extensions zu erweitern. Soll diese in subprojects oder allprojects konfiguriert werden, muss dies über die configure<?>-Anweisung geschehen. Für Spring Boot und Kotlin müssen die JavaLanguageVersion in der JavaPluginExtension, die compilerOptions in der KotlinJvmProjectExtension und JPA-relevante Settings in der AllOpenExtension konfiguriert werden.

// ...

subprojects {

    // ...

    configure<JavaPluginExtension> {  
        toolchain {  
            languageVersion = JavaLanguageVersion.of(21)  
        }
    }  
    
    configure<KotlinJvmProjectExtension> {  
        compilerOptions {  
            freeCompilerArgs.add("-Xjsr305=strict")  
        }  
    }
  
    configure<AllOpenExtension> {  
        annotation("jakarta.persistence.Entity")  
        annotation("jakarta.persistence.MappedSuperclass")  
        annotation("jakarta.persistence.Embeddable")  
    }

    // ...
}

// ...

subprojects {

    // ...

    configure<JavaPluginExtension> {  
        toolchain {  
            languageVersion = JavaLanguageVersion.of(21)  
        }
    }  
    
    configure<KotlinJvmProjectExtension> {  
        compilerOptions {  
            freeCompilerArgs.add("-Xjsr305=strict")  
        }  
    }
  
    configure<AllOpenExtension> {  
        annotation("jakarta.persistence.Entity")  
        annotation("jakarta.persistence.MappedSuperclass")  
        annotation("jakarta.persistence.Embeddable")  
    }

    // ...
}

Zu guter Letzt werden die Tasks der subprojects konfiguriert. In diesem Fall wird  die Nutzung der JUnitPlatform für Tasks des Typs Test angewiesen und der BootJar-Task deaktiviert, da ansonsten das Spring-Boot-Plugin in allen konfigurierten Modulen eine Main-Methode sucht, aber nicht findet.

// ...

subprojects {

    // ...
    tasks {  
        withType<Test> {  
            useJUnitPlatform()  
        }  
        withType<BootJar> {  
            enabled = false  
        }
    }  
}

// ...

subprojects {

    // ...
    tasks {  
        withType<Test> {  
            useJUnitPlatform()  
        }  
        withType<BootJar> {  
            enabled = false  
        }
    }  
}

Damit sieht die vollständige build.gradle.kts wie folgt aus:

// build.gradle.kts

import org.jetbrains.kotlin.allopen.gradle.AllOpenExtension  
import org.jetbrains.kotlin.gradle.dsl.KotlinJvmProjectExtension  

plugins {  
    kotlin("jvm") version "1.9.25" apply false  
    kotlin("plugin.spring") version "1.9.25" apply false  
    id("org.springframework.boot") version "3.5.7" apply false  
    id("io.spring.dependency-management") version "1.1.7" apply false  
    kotlin("plugin.jpa") version "1.9.25" apply false  
}  

allprojects {  
    group = "consulting.atra.hexagon"  
    version = "0.0.0"  
}  

subprojects {  
    apply {  
        plugin("java-library")  
        plugin("org.jetbrains.kotlin.jvm")  
        plugin("org.springframework.boot")  
        plugin("org.jetbrains.kotlin.plugin.spring")  
        plugin("io.spring.dependency-management")  
    }  
    val annotationProcessor by configurations  
    val compileOnly by configurations  
    val implementation by configurations  
    val testImplementation by configurations  
    val testRuntimeOnly by configurations  
    configurations {  
        compileOnly.extendsFrom(annotationProcessor)  
    }  
    dependencies {  
        implementation("org.jetbrains.kotlin:kotlin-reflect")  
        testImplementation("org.springframework.boot:spring-boot-starter-test")  
        testImplementation("org.jetbrains.kotlin:kotlin-test-junit5")  
        testRuntimeOnly("org.junit.platform:junit-platform-launcher")  
    }  
    configure<JavaPluginExtension> {  
        toolchain {  
            languageVersion = JavaLanguageVersion.of(21)  
        }  
    }  
    configure<KotlinJvmProjectExtension> {  
        compilerOptions {  
            freeCompilerArgs.add("-Xjsr305=strict")  
        }  
    }  
    configure<AllOpenExtension> {  
        annotation("jakarta.persistence.Entity")  
        annotation("jakarta.persistence.MappedSuperclass")  
        annotation("jakarta.persistence.Embeddable")  
    }  
    tasks {  
        withType<Test> {  
            useJUnitPlatform()  
        }

        withType<BootJar> {  
            enabled = false  
        }  
    }  
}

// build.gradle.kts

import org.jetbrains.kotlin.allopen.gradle.AllOpenExtension  
import org.jetbrains.kotlin.gradle.dsl.KotlinJvmProjectExtension  

plugins {  
    kotlin("jvm") version "1.9.25" apply false  
    kotlin("plugin.spring") version "1.9.25" apply false  
    id("org.springframework.boot") version "3.5.7" apply false  
    id("io.spring.dependency-management") version "1.1.7" apply false  
    kotlin("plugin.jpa") version "1.9.25" apply false  
}  

allprojects {  
    group = "consulting.atra.hexagon"  
    version = "0.0.0"  
}  

subprojects {  
    apply {  
        plugin("java-library")  
        plugin("org.jetbrains.kotlin.jvm")  
        plugin("org.springframework.boot")  
        plugin("org.jetbrains.kotlin.plugin.spring")  
        plugin("io.spring.dependency-management")  
    }  
    val annotationProcessor by configurations  
    val compileOnly by configurations  
    val implementation by configurations  
    val testImplementation by configurations  
    val testRuntimeOnly by configurations  
    configurations {  
        compileOnly.extendsFrom(annotationProcessor)  
    }  
    dependencies {  
        implementation("org.jetbrains.kotlin:kotlin-reflect")  
        testImplementation("org.springframework.boot:spring-boot-starter-test")  
        testImplementation("org.jetbrains.kotlin:kotlin-test-junit5")  
        testRuntimeOnly("org.junit.platform:junit-platform-launcher")  
    }  
    configure<JavaPluginExtension> {  
        toolchain {  
            languageVersion = JavaLanguageVersion.of(21)  
        }  
    }  
    configure<KotlinJvmProjectExtension> {  
        compilerOptions {  
            freeCompilerArgs.add("-Xjsr305=strict")  
        }  
    }  
    configure<AllOpenExtension> {  
        annotation("jakarta.persistence.Entity")  
        annotation("jakarta.persistence.MappedSuperclass")  
        annotation("jakarta.persistence.Embeddable")  
    }  
    tasks {  
        withType<Test> {  
            useJUnitPlatform()  
        }

        withType<BootJar> {  
            enabled = false  
        }  
    }  
}

Kapitel 2.3: application/build.gradle.kts

Da die build.gradle.kts des Hauptordners bereits umfangreich konfiguriert wurde, kommen die einzelnen Module mit einer minimalen Konfiguration aus.

// application/build.gradle.kts

plugins {  
    id("application")  
    id("org.springframework.boot")  
    id("io.spring.dependency-management")  
}  

dependencies {  
    implementation("org.springframework.boot:spring-boot-starter-data-jpa")  
    implementation("org.springframework.boot:spring-boot-starter-web")  
    implementation("com.fasterxml.jackson.module:jackson-module-kotlin")  
    developmentOnly("org.springframework.boot:spring-boot-devtools")  
    runtimeOnly("com.h2database:h2")  
    annotationProcessor("org.springframework.boot:spring-boot-configuration-processor")  
}

// application/build.gradle.kts

plugins {  
    id("application")  
    id("org.springframework.boot")  
    id("io.spring.dependency-management")  
}  

dependencies {  
    implementation("org.springframework.boot:spring-boot-starter-data-jpa")  
    implementation("org.springframework.boot:spring-boot-starter-web")  
    implementation("com.fasterxml.jackson.module:jackson-module-kotlin")  
    developmentOnly("org.springframework.boot:spring-boot-devtools")  
    runtimeOnly("com.h2database:h2")  
    annotationProcessor("org.springframework.boot:spring-boot-configuration-processor")  
}

Kapitel 3: Die Abhängigkeiten

Um das Verwalten von Abhängigkeiten noch leichter zu gestalten und das io.spring.dependency-management-Plugin abzulösen, kann ein Gradle Version Catalog verwendet werden. Dazu wird die Datei gradle/libs.versions.toml erstellt. Die Katalog-Datei gliedert sich in 4 relevante Segmente:

• [versions]: Definiert die Versionen über einen eindeutigen Schlüssel. Versionen können über den Schlüssel von [libraries] und [plugins] referenziert werden.
• [libraries]: Bibliotheken mit einer eindeutigen Referenz. Dies wird zum Laden der BOMs verwendet, um nicht alle Bibliotheken selber verwalten zu müssen.
• [plugins]: Gradle-Plugins, welche über eine eindeutige Referenz in den Modulen verwendet werden können.
• [bundles]: Kollektion von [libraries], ermöglicht es, gemeinsam auftretende Bibliotheken gebündelt zu definieren.

# gradle/libs.versions.toml
[versions]  
kotlin = "1.9.25"  
spring-boot = "3.5.7"  
[libraries]  
bom-spring-boot = { group = "org.springframework.boot", name = "spring-boot-dependencies", version.ref = "spring-boot" }  
h2 = { group = "com.h2database", name = "h2"}  
junit-platform = { group = "org.junit.platform", name = "junit-platform-launcher" }  
kotlin-jackson = { group = "com.fasterxml.jackson.module", name = "jackson-module-kotlin" }  
kotlin-reflect = { group = "org.jetbrains.kotlin", name = "kotlin-reflect" }  
kotlin-test = { group = "org.jetbrains.kotlin", name = "kotlin-test-junit5" }  
spring-boot = { group = "org.springframework.boot", name = "spring-boot-starter" }  
spring-boot-configuration = { group = "org.springframework.boot", name = "spring-boot-configuration-processor" }  
spring-boot-devtools = { group = "org.springframework.boot", name = "spring-boot-devtools" }  
spring-boot-test = { group = "org.springframework.boot", name = "spring-boot-starter-test" }  
spring-boot-data-jpa = { group = "org.springframework.boot", name = "spring-boot-starter-data-jpa" }  
spring-boot-validation = { group = "org.springframework.boot", name = "spring-boot-starter-validation" }  
spring-boot-web = { group = "org.springframework.boot", name = "spring-boot-starter-web" }  

[plugins]  
kotlin-jvm = { id = "org.jetbrains.kotlin.jvm", version.ref = "kotlin" }  
kotlin-jpa = { id = "org.jetbrains.kotlin.plugin.jpa", version.ref = "kotlin" }  
kotlin-spring = { id = "org.jetbrains.kotlin.plugin.spring", version.ref = "kotlin" }  
spring-boot = { id = "org.springframework.boot", version.ref = "spring-boot" }  

[bundles]  
spring-boot-web = ["spring-boot-validation", "spring-boot-web", "kotlin-jackson"]  
spring-boot-test = ["spring-boot-test", "kotlin-test"]

# gradle/libs.versions.toml
[versions]  
kotlin = "1.9.25"  
spring-boot = "3.5.7"  
[libraries]  
bom-spring-boot = { group = "org.springframework.boot", name = "spring-boot-dependencies", version.ref = "spring-boot" }  
h2 = { group = "com.h2database", name = "h2"}  
junit-platform = { group = "org.junit.platform", name = "junit-platform-launcher" }  
kotlin-jackson = { group = "com.fasterxml.jackson.module", name = "jackson-module-kotlin" }  
kotlin-reflect = { group = "org.jetbrains.kotlin", name = "kotlin-reflect" }  
kotlin-test = { group = "org.jetbrains.kotlin", name = "kotlin-test-junit5" }  
spring-boot = { group = "org.springframework.boot", name = "spring-boot-starter" }  
spring-boot-configuration = { group = "org.springframework.boot", name = "spring-boot-configuration-processor" }  
spring-boot-devtools = { group = "org.springframework.boot", name = "spring-boot-devtools" }  
spring-boot-test = { group = "org.springframework.boot", name = "spring-boot-starter-test" }  
spring-boot-data-jpa = { group = "org.springframework.boot", name = "spring-boot-starter-data-jpa" }  
spring-boot-validation = { group = "org.springframework.boot", name = "spring-boot-starter-validation" }  
spring-boot-web = { group = "org.springframework.boot", name = "spring-boot-starter-web" }  

[plugins]  
kotlin-jvm = { id = "org.jetbrains.kotlin.jvm", version.ref = "kotlin" }  
kotlin-jpa = { id = "org.jetbrains.kotlin.plugin.jpa", version.ref = "kotlin" }  
kotlin-spring = { id = "org.jetbrains.kotlin.plugin.spring", version.ref = "kotlin" }  
spring-boot = { id = "org.springframework.boot", version.ref = "spring-boot" }  

[bundles]  
spring-boot-web = ["spring-boot-validation", "spring-boot-web", "kotlin-jackson"]  
spring-boot-test = ["spring-boot-test", "kotlin-test"]

Durch die Nutzung des Version Catalog fällt eine Anpassung der build.gradle.kts an. Zum einen wird die Version-Catalog-Referenz für plugins und dependencies genutzt, zum anderen wird das zuvor erwähnte io.spring.dependency-management-Plugin entfernt. Weiterhin müssen die BOMs in alle DependencyConfiguration geladen werden, damit Versionen, die von einer BOM verwaltet werden, auch referenziert werden können. Plugins werden über die alias()-Anweisung definiert, wobei zu beachten ist, dass diese in subprojects und allprojects so nicht zur Verfügung steht. BOMs müssen einzeln, nicht als [bundles], über die platform()-Anweisung in jeder genutzten DependencyConfiguration hinterlegt werden.

// ...
plugins {  
    alias(libs.plugins.kotlin.jvm) apply false  
    alias(libs.plugins.kotlin.spring) apply false  
    alias(libs.plugins.kotlin.jpa) apply false  
    alias(libs.plugins.spring.boot) apply false  
}

// ...
subprojects {
    // ...
    val annotationProcessor by configurations  
    val compileOnly by configurations  
    val developmentOnly by configurations  
    val implementation by configurations  
    val testImplementation by configurations  
    val testRuntimeOnly by configurations  
    // ... 
    dependencies {  
        annotationProcessor(platform(rootProject.libs.bom.spring.boot))  
        compileOnly(platform(rootProject.libs.bom.spring.boot))  
        developmentOnly(platform(rootProject.libs.bom.spring.boot))  
        implementation(platform(rootProject.libs.bom.spring.boot))  
        testImplementation(platform(rootProject.libs.bom.spring.boot))  
        testRuntimeOnly(platform(rootProject.libs.bom.spring.boot))  
        implementation(rootProject.libs.kotlin.reflect)  
        testImplementation(rootProject.libs.bundles.spring.boot.test)  
        testRuntimeOnly(rootProject.libs.junit.platform)  
    }
    // ...
}

// ...
plugins {  
    alias(libs.plugins.kotlin.jvm) apply false  
    alias(libs.plugins.kotlin.spring) apply false  
    alias(libs.plugins.kotlin.jpa) apply false  
    alias(libs.plugins.spring.boot) apply false  
}

// ...
subprojects {
    // ...
    val annotationProcessor by configurations  
    val compileOnly by configurations  
    val developmentOnly by configurations  
    val implementation by configurations  
    val testImplementation by configurations  
    val testRuntimeOnly by configurations  
    // ... 
    dependencies {  
        annotationProcessor(platform(rootProject.libs.bom.spring.boot))  
        compileOnly(platform(rootProject.libs.bom.spring.boot))  
        developmentOnly(platform(rootProject.libs.bom.spring.boot))  
        implementation(platform(rootProject.libs.bom.spring.boot))  
        testImplementation(platform(rootProject.libs.bom.spring.boot))  
        testRuntimeOnly(platform(rootProject.libs.bom.spring.boot))  
        implementation(rootProject.libs.kotlin.reflect)  
        testImplementation(rootProject.libs.bundles.spring.boot.test)  
        testRuntimeOnly(rootProject.libs.junit.platform)  
    }
    // ...
}

Die Leichtigkeit des Gradle Version Catalogs fällt erst richtig bei den einzelnen Modulen auf. Die build.gradle.kts des application-Moduls wird mit den neuen Änderungen noch schlanker.

// application/build.gradle.kts

plugins {  
    id("application")  
    alias(libs.plugins.spring.boot)  
    alias(libs.plugins.kotlin.jpa)  
}  

dependencies {  
    implementation(libs.spring.boot.data.jpa)  
    implementation(libs.bundles.spring.boot.web)  
    developmentOnly(libs.spring.boot.devtools)  
    runtimeOnly(libs.h2)  
    annotationProcessor(libs.spring.boot.configuration)  
}

// application/build.gradle.kts

plugins {  
    id("application")  
    alias(libs.plugins.spring.boot)  
    alias(libs.plugins.kotlin.jpa)  
}  

dependencies {  
    implementation(libs.spring.boot.data.jpa)  
    implementation(libs.bundles.spring.boot.web)  
    developmentOnly(libs.spring.boot.devtools)  
    runtimeOnly(libs.h2)  
    annotationProcessor(libs.spring.boot.configuration)  
}

Kapitel 4: Die Domain

classDiagram
    class Product {
        <<data class>>
        +Long? id
        +String name
        +Double price
        +applyDiscount(Double discount)
    }

    class FindAllProductsUseCase {
        <<interface>>
        +findAllProducts() List~Product~
    }

    class FindProductByIdUseCase {
        <<interface>>
        +findProductById(Long id) Product?
    }

    class CreateProductUseCase {
        <<interface>>
        +createProduct(Product product) Product
    }
 
   class ApplyDiscountToProductUseCase {
        <<interface>>
        +applyDiscountToProduct(Long id, Double discount) Product
    }

    class SaveProductUseCase {
        <<interface>>
        +saveProduct(Product product) Product
    }

    class ProductsEndpointPort {
        <<interface>>
    }

    class ProductsPersistencePort {
        <<interface>>
    }

    ProductsEndpointPort --|> FindAllProductsUseCase
    ProductsEndpointPort --|> FindProductByIdUseCase
    ProductsEndpointPort --|> CreateProductUseCase
    ProductsEndpointPort --|> ApplyDiscountToProductUseCase
    ProductsPersistencePort --|> FindAllProductsUseCase
    ProductsPersistencePort --|> FindProductByIdUseCase
    ProductsPersistencePort --|> SaveProductUseCase
    FindAllProductsUseCase ..> Product : uses
    FindProductByIdUseCase ..> Product : uses
    CreateProductUseCase ..> Product : uses
    ApplyDiscountToProductUseCase ..> Product : uses
    SaveProductUseCase ..> Product : uses

classDiagram
    class Product {
        <<data class>>
        +Long? id
        +String name
        +Double price
        +applyDiscount(Double discount)
    }

    class FindAllProductsUseCase {
        <<interface>>
        +findAllProducts() List~Product~
    }

    class FindProductByIdUseCase {
        <<interface>>
        +findProductById(Long id) Product?
    }

    class CreateProductUseCase {
        <<interface>>
        +createProduct(Product product) Product
    }
 
   class ApplyDiscountToProductUseCase {
        <<interface>>
        +applyDiscountToProduct(Long id, Double discount) Product
    }

    class SaveProductUseCase {
        <<interface>>
        +saveProduct(Product product) Product
    }

    class ProductsEndpointPort {
        <<interface>>
    }

    class ProductsPersistencePort {
        <<interface>>
    }

    ProductsEndpointPort --|> FindAllProductsUseCase
    ProductsEndpointPort --|> FindProductByIdUseCase
    ProductsEndpointPort --|> CreateProductUseCase
    ProductsEndpointPort --|> ApplyDiscountToProductUseCase
    ProductsPersistencePort --|> FindAllProductsUseCase
    ProductsPersistencePort --|> FindProductByIdUseCase
    ProductsPersistencePort --|> SaveProductUseCase
    FindAllProductsUseCase ..> Product : uses
    FindProductByIdUseCase ..> Product : uses
    CreateProductUseCase ..> Product : uses
    ApplyDiscountToProductUseCase ..> Product : uses
    SaveProductUseCase ..> Product : uses

Das domain-Modul bildet den Kern der hexagonalen Architektur. Hier residiert die reine Geschäftslogik, vollständig entkoppelt von technischen Frameworks oder Infrastruktur-Details. Gradle-seitig ist für dieses Modul keine weitere Konfiguration notwendig, da es lediglich auf der Standard-Kotlin-Konfiguration aus dem Root-Projekt aufbaut. Es wird bewusst darauf verzichtet, Abhängigkeiten zu Frameworks wie Spring Boot hinzuzufügen.

Das zentrale Domänenmodell wird durch die Klasse Product repräsentiert. Im Gegensatz zur vorherigen Implementierung ist dies nun eine reine Kotlin-Klasse ohne JPA-Annotationen, angereichert mit fachlicher Logik wie der Preiskalkulation.

// domain/src/main/kotlin/consulting/atra/hexagon/domain/Product.kt

package consulting.atra.hexagon.domain  

data class Product(  
    val id: Long? = null,  
    var name: String,  
    var price: Double,  
) {  
    fun applyDiscount(discount: Double) {  
        price *= (1 - discount / 100)  
    }  
}

// domain/src/main/kotlin/consulting/atra/hexagon/domain/Product.kt

package consulting.atra.hexagon.domain  

data class Product(  
    val id: Long? = null,  
    var name: String,  
    var price: Double,  
) {  
    fun applyDiscount(discount: Double) {  
        price *= (1 - discount / 100)  
    }  
}

Die Interaktion mit der Domäne wird über Use Cases definiert. Diese Interfaces beschreiben, was mit der Domäne getan werden kann, ohne vorzuschreiben, wie dies technisch umgesetzt wird.

/ domain/src/main/kotlin/consulting/atra/hexagon/domain/ProductUseCases.kt

package consulting.atra.hexagon.domain  

interface FindAllProductsUseCase {  
    fun findAllProducts(): List<Product>  
}  

interface FindProductByIdUseCase {  
    fun findProductById(id: Long): Product?  
}  

interface CreateProductUseCase {  
    fun createProduct(product: Product): Product  
}  

interface ApplyDiscountToProductUseCase {  
    fun applyDiscountToProduct(id: Long, discount: Double): Product  
}  

interface SaveProductUseCase {  
    fun saveProduct(product: Product): Product  
}

/ domain/src/main/kotlin/consulting/atra/hexagon/domain/ProductUseCases.kt

package consulting.atra.hexagon.domain  

interface FindAllProductsUseCase {  
    fun findAllProducts(): List<Product>  
}  

interface FindProductByIdUseCase {  
    fun findProductById(id: Long): Product?  
}  

interface CreateProductUseCase {  
    fun createProduct(product: Product): Product  
}  

interface ApplyDiscountToProductUseCase {  
    fun applyDiscountToProduct(id: Long, discount: Double): Product  
}  

interface SaveProductUseCase {  
    fun saveProduct(product: Product): Product  
}

Um die Kommunikation nach außen zu ermöglichen, werden Ports definiert. Der ProductsEndpointPort fungiert als „Driving Port“ (Eingang), der von der Außenwelt (z.B. REST API) aufgerufen wird. Der ProductsPersistencePort dient als „Driven Port“ (Ausgang), über den die Domäne Daten speichert oder lädt, ohne die konkrete Datenbanktechnologie zu kennen.

// domain/src/main/kotlin/consulting/atra/hexagon/domain/ProductPorts.kt

package consulting.atra.hexagon.domain  

interface ProductsEndpointPort :  
    FindAllProductsUseCase,  
    FindProductByIdUseCase,  
    CreateProductUseCase,  
    ApplyDiscountToProductUseCase  

interface ProductsPersistencePort :  
    FindAllProductsUseCase,  
    FindProductByIdUseCase,  
    SaveProductUseCase

// domain/src/main/kotlin/consulting/atra/hexagon/domain/ProductPorts.kt

package consulting.atra.hexagon.domain  

interface ProductsEndpointPort :  
    FindAllProductsUseCase,  
    FindProductByIdUseCase,  
    CreateProductUseCase,  
    ApplyDiscountToProductUseCase  

interface ProductsPersistencePort :  
    FindAllProductsUseCase,  
    FindProductByIdUseCase,  
    SaveProductUseCase

Kapitel 5: Der Eingangs-Adapter

classDiagram
    class ProductsEndpoint {
        <<interface>>
        +list() List~ProductResponse~
        +create(ProductRequest product) ProductResponse
        +get(Long id) ProductResponse?
        +update(Long id, Double discount) ProductResponse?
    }

    class ProductsEndpointAdapter {
        <<RestController>>
        -ProductsEndpointPort port
        +list() List~ProductResponse~
        +create(ProductRequest product) ProductResponse
        +get(Long id) ProductResponse?
        +update(Long id, Double discount) ProductResponse?
    }

    class ProductsEndpointPort {
        <<interface / from domain>>
    }

    class ProductRequest {
        <<data class>>
        +String name
        +Double price
    }

    class ProductResponse {
        <<data class>>
        +Long id
        +String name
        +Double price
    }

    class Product {
        <<data class / from domain>>
    }

    ProductsEndpointAdapter ..|> ProductsEndpoint : implements
    ProductsEndpointAdapter --> ProductsEndpointPort : uses port
    ProductsEndpointAdapter ..> ProductRequest : receives
    ProductsEndpointAdapter ..> ProductResponse : returns
    ProductsEndpointAdapter ..> Product : maps to/from

classDiagram
    class ProductsEndpoint {
        <<interface>>
        +list() List~ProductResponse~
        +create(ProductRequest product) ProductResponse
        +get(Long id) ProductResponse?
        +update(Long id, Double discount) ProductResponse?
    }

    class ProductsEndpointAdapter {
        <<RestController>>
        -ProductsEndpointPort port
        +list() List~ProductResponse~
        +create(ProductRequest product) ProductResponse
        +get(Long id) ProductResponse?
        +update(Long id, Double discount) ProductResponse?
    }

    class ProductsEndpointPort {
        <<interface / from domain>>
    }

    class ProductRequest {
        <<data class>>
        +String name
        +Double price
    }

    class ProductResponse {
        <<data class>>
        +Long id
        +String name
        +Double price
    }

    class Product {
        <<data class / from domain>>
    }

    ProductsEndpointAdapter ..|> ProductsEndpoint : implements
    ProductsEndpointAdapter --> ProductsEndpointPort : uses port
    ProductsEndpointAdapter ..> ProductRequest : receives
    ProductsEndpointAdapter ..> ProductResponse : returns
    ProductsEndpointAdapter ..> Product : maps to/from

Der Eingangs-Adapter (Driving Adapter) ist verantwortlich für die Kommunikation von außen in die Anwendung hinein. In diesem Fall handelt es sich um einen REST-Controller. Das Modul adapters:endpoint erhält Zugriff auf das domain-Modul sowie auf die benötigten Web-Bibliotheken.

// adapters/endpoint/build.gradle.kts

dependencies {  
    implementation(project(":domain"))  
    implementation(libs.bundles.spring.boot.web)  
}

// adapters/endpoint/build.gradle.kts

dependencies {  
    implementation(project(":domain"))  
    implementation(libs.bundles.spring.boot.web)  
}

Um die API-Schicht sauber von der Domäne zu trennen, werden separate Data Transfer Objects (DTOs) für Requests und Responses definiert. Dies verhindert, dass Änderungen an der internen Domänenstruktur ungewollt die externe API beeinflussen.

// adapters/endpoint/src/main/kotlin/consulting/atra/hexagon/adapters/endpoint/ProductRequest.kt

package consulting.atra.hexagon.adapters.endpoint  

data class ProductRequest(  
    var name: String, 
    var price: Double,  
)

// adapters/endpoint/src/main/kotlin/consulting/atra/hexagon/adapters/endpoint/ProductRequest.kt

package consulting.atra.hexagon.adapters.endpoint  

data class ProductRequest(  
    var name: String, 
    var price: Double,  
)

// adapters/endpoint/src/main/kotlin/consulting/atra/hexagon/adapters/endpoint/ProductResponse.kt

package consulting.atra.hexagon.adapters.endpoint  

data class ProductResponse(  
    var id: Long,  
    var name: String,  
    var price: Double,  
)

// adapters/endpoint/src/main/kotlin/consulting/atra/hexagon/adapters/endpoint/ProductResponse.kt

package consulting.atra.hexagon.adapters.endpoint  

data class ProductResponse(  
    var id: Long,  
    var name: String,  
    var price: Double,  
)

Die Konvertierung zwischen DTOs und Domänen-Objekten erfolgt durch explizite Mapping-Funktionen.

// adapters/endpoint/src/main/kotlin/consulting/atra/hexagon/adapters/endpoint/ProductMapping.kt

package consulting.atra.hexagon.adapters.endpoint  

import consulting.atra.hexagon.domain.Product  

fun Product.toResponse() =  
    ProductResponse(  
        id = id!!,  
        name = name,  
        price = price,  
    )  

fun ProductRequest.toDomain() =  
    Product(  
        name = name,  
        price = price,  
    )  

fun List<Product>.toResponses() =  
    map { it.toResponse() }

// adapters/endpoint/src/main/kotlin/consulting/atra/hexagon/adapters/endpoint/ProductMapping.kt

package consulting.atra.hexagon.adapters.endpoint  

import consulting.atra.hexagon.domain.Product  

fun Product.toResponse() =  
    ProductResponse(  
        id = id!!,  
        name = name,  
        price = price,  
    )  

fun ProductRequest.toDomain() =  
    Product(  
        name = name,  
        price = price,  
    )  

fun List<Product>.toResponses() =  
    map { it.toResponse() }

Die Schnittstelle des REST-Controllers wird zunächst als Interface definiert, um die technische Definition der Endpunkte von der Implementierung zu trennen.

// adapters/endpoint/src/main/kotlin/consulting/atra/hexagon/adapters/endpoint/ProductsEndpoint.kt

package consulting.atra.hexagon.adapters.endpoint  

import org.springframework.web.bind.annotation.GetMapping  
import org.springframework.web.bind.annotation.PatchMapping  
import org.springframework.web.bind.annotation.PathVariable  
import org.springframework.web.bind.annotation.PostMapping  
import org.springframework.web.bind.annotation.RequestBody  
import org.springframework.web.bind.annotation.RequestMapping  
import org.springframework.web.bind.annotation.RequestParam  

@RequestMapping("/api/v1/products")  
interface ProductsEndpoint {  

    @GetMapping  
    fun list(): List<ProductResponse>  

    @PostMapping  
    fun create(@RequestBody product: ProductRequest): ProductResponse  

    @GetMapping("/{id}")  
    fun get(@PathVariable id: Long): ProductResponse?  

    @PatchMapping("/{id}")  
    fun update(@PathVariable id: Long, @RequestParam discount: Double): ProductResponse?  

}

// adapters/endpoint/src/main/kotlin/consulting/atra/hexagon/adapters/endpoint/ProductsEndpoint.kt

package consulting.atra.hexagon.adapters.endpoint  

import org.springframework.web.bind.annotation.GetMapping  
import org.springframework.web.bind.annotation.PatchMapping  
import org.springframework.web.bind.annotation.PathVariable  
import org.springframework.web.bind.annotation.PostMapping  
import org.springframework.web.bind.annotation.RequestBody  
import org.springframework.web.bind.annotation.RequestMapping  
import org.springframework.web.bind.annotation.RequestParam  

@RequestMapping("/api/v1/products")  
interface ProductsEndpoint {  

    @GetMapping  
    fun list(): List<ProductResponse>  

    @PostMapping  
    fun create(@RequestBody product: ProductRequest): ProductResponse  

    @GetMapping("/{id}")  
    fun get(@PathVariable id: Long): ProductResponse?  

    @PatchMapping("/{id}")  
    fun update(@PathVariable id: Long, @RequestParam discount: Double): ProductResponse?  

}

Die eigentliche Implementierung des Adapters, ProductsEndpointAdapter, nutzt den ProductsEndpointPort der Domäne, um die Geschäftslogik auszuführen. Eingehende Requests werden in Domänenobjekte umgewandelt, an den Port übergeben und das Ergebnis wieder als Response-DTO zurückgegeben.

// adapters/endpoint/src/main/kotlin/consulting/atra/hexagon/adapters/endpoint/ProductsEndpointAdapter.kt

package consulting.atra.hexagon.adapters.endpoint  

import consulting.atra.hexagon.domain.ProductEndpointPort  
import org.springframework.web.bind.annotation.RestController  

@RestController  
class ProductsEndpointAdapter (  
    private val port: ProductsEndpointPort,  
) : ProductsEndpoint {  

    override fun list(): List<ProductResponse> =  
        port.findAllProducts().toResponses()  

    override fun create(product: ProductRequest): ProductResponse =  
        port.createProduct(product.toDomain()).toResponse()  

    override fun get(id: Long): ProductResponse? =  
        port.findProductById(id)?.toResponse()  

    override fun update(  
        id: Long,  
        discount: Double  
    ): ProductResponse? =  
        port.applyDiscountToProduct(id, discount)?.toResponse()  
}

// adapters/endpoint/src/main/kotlin/consulting/atra/hexagon/adapters/endpoint/ProductsEndpointAdapter.kt

package consulting.atra.hexagon.adapters.endpoint  

import consulting.atra.hexagon.domain.ProductEndpointPort  
import org.springframework.web.bind.annotation.RestController  

@RestController  
class ProductsEndpointAdapter (  
    private val port: ProductsEndpointPort,  
) : ProductsEndpoint {  

    override fun list(): List<ProductResponse> =  
        port.findAllProducts().toResponses()  

    override fun create(product: ProductRequest): ProductResponse =  
        port.createProduct(product.toDomain()).toResponse()  

    override fun get(id: Long): ProductResponse? =  
        port.findProductById(id)?.toResponse()  

    override fun update(  
        id: Long,  
        discount: Double  
    ): ProductResponse? =  
        port.applyDiscountToProduct(id, discount)?.toResponse()  
}

Kapitel 6: Der Ausgangs-Adapter

classDiagram
    class ProductEntity {
        <<Entity / data class>>
        +Long? id
        +String name
        +Double price
    }

    class ProductsRepository {
        <<interface>>
    }

    class ProductsPersistenceAdapter {
        <<Service>>
        -ProductsRepository repository
        +findAllProducts() List~Product~
        +findProductById(Long id) Product?
        +saveProduct(Product product) Product
    }

    class ProductsPersistencePort {
        <<interface / from domain>>
    }

    class Product {
        <<data class / from domain>>
    }

    ProductsPersistenceAdapter ..|> ProductsPersistencePort : implements
    ProductsPersistenceAdapter --> ProductsRepository : repository
    ProductsRepository ..> ProductEntity : manages
    ProductsPersistenceAdapter ..> ProductEntity : maps to/from
    ProductsPersistenceAdapter ..> Product : maps to/from

classDiagram
    class ProductEntity {
        <<Entity / data class>>
        +Long? id
        +String name
        +Double price
    }

    class ProductsRepository {
        <<interface>>
    }

    class ProductsPersistenceAdapter {
        <<Service>>
        -ProductsRepository repository
        +findAllProducts() List~Product~
        +findProductById(Long id) Product?
        +saveProduct(Product product) Product
    }

    class ProductsPersistencePort {
        <<interface / from domain>>
    }

    class Product {
        <<data class / from domain>>
    }

    ProductsPersistenceAdapter ..|> ProductsPersistencePort : implements
    ProductsPersistenceAdapter --> ProductsRepository : repository
    ProductsRepository ..> ProductEntity : manages
    ProductsPersistenceAdapter ..> ProductEntity : maps to/from
    ProductsPersistenceAdapter ..> Product : maps to/from

Auf der anderen Seite des Hexagons befindet sich der Ausgangs-Adapter (Driven Adapter), der für die Persistenz zuständig ist. Das Modul adapters:persistence implementiert die technischen Details der Datenspeicherung mittels JPA und H2.

// adapters/persistence/build.gradle.kts

plugins {  
    alias(libs.plugins.kotlin.jpa)  
}  

dependencies {  
    implementation(project(":domain"))  
    implementation(libs.spring.boot.data.jpa)  
    runtimeOnly(libs.h2)  
}

// adapters/persistence/build.gradle.kts

plugins {  
    alias(libs.plugins.kotlin.jpa)  
}  

dependencies {  
    implementation(project(":domain"))  
    implementation(libs.spring.boot.data.jpa)  
    runtimeOnly(libs.h2)  
}

Auch hier wird eine strikte Trennung vorgenommen: Die ProductEntity ist eine JPA-spezifische Klasse, die mit Datenbank-Annotationen versehen ist. Sie ist von der Domänenklasse Product getrennt, um das Domänenmodell nicht mit Persistenzdetails zu verunreinigen.

// adapters/persistence/src/main/kotlin/consulting/atra/hexagon/adapters/persistence/ProductEntity.kt

package consulting.atra.hexagon.adapters.persistence  

import jakarta.persistence.Entity  
import jakarta.persistence.GeneratedValue  
import jakarta.persistence.Id  

@Entity  
data class ProductEntity(  
    @Id  
    @GeneratedValue
    var id: Long? = null,  

    var name: String,  

    var price: Double,  
)

// adapters/persistence/src/main/kotlin/consulting/atra/hexagon/adapters/persistence/ProductEntity.kt

package consulting.atra.hexagon.adapters.persistence  

import jakarta.persistence.Entity  
import jakarta.persistence.GeneratedValue  
import jakarta.persistence.Id  

@Entity  
data class ProductEntity(  
    @Id  
    @GeneratedValue
    var id: Long? = null,  

    var name: String,  

    var price: Double,  
)

Das ProductsRepository bleibt ein klassisches Spring Data JPA Repository.

// adapters/persistence/src/main/kotlin/consulting/atra/hexagon/adapters/persistence/ProductsRepository.kt

package consulting.atra.hexagon.adapters.persistence  

import org.springframework.data.jpa.repository.JpaRepository  
interface ProductsRepository : JpaRepository<ProductEntity, Long>

// adapters/persistence/src/main/kotlin/consulting/atra/hexagon/adapters/persistence/ProductsRepository.kt

package consulting.atra.hexagon.adapters.persistence  

import org.springframework.data.jpa.repository.JpaRepository  
interface ProductsRepository : JpaRepository<ProductEntity, Long>

Der ProductsPersistenceAdapter implementiert schließlich den ProductsPersistencePort der Domäne. Er übersetzt die Aufrufe der Domäne in Datenbankoperationen und konvertiert zwischen Product (Domäne) und ProductEntity (Datenbank). Damit bleibt die Domäne vollständig unabhängig von der verwendeten Datenbanktechnologie.

// adapters/persistence/src/main/kotlin/consulting/atra/hexagon/adapters/persistence/ProductsPersistenceAdapter.kt

package consulting.atra.hexagon.adapters.persistence  

import consulting.atra.hexagon.domain.Product  
import consulting.atra.hexagon.domain.ProductsPersistencePort  
import org.springframework.data.repository.findByIdOrNull  
import org.springframework.stereotype.Service  

@Service  
class ProductsPersistenceAdapter(  
    private val repository: ProductsRepository,  
) : ProductsPersistencePort {  
    override fun findAllProducts(): List<Product> =  
        repository.findAll().toDomains()  

    override fun findProductById(id: Long): Product? =  
        repository.findByIdOrNull(id)?.let { return it.toDomain() }  

    override fun saveProduct(product: Product): Product =  
        repository.save(product.toEntity()).toDomain()  
}

// adapters/persistence/src/main/kotlin/consulting/atra/hexagon/adapters/persistence/ProductsPersistenceAdapter.kt

package consulting.atra.hexagon.adapters.persistence  

import consulting.atra.hexagon.domain.Product  
import consulting.atra.hexagon.domain.ProductsPersistencePort  
import org.springframework.data.repository.findByIdOrNull  
import org.springframework.stereotype.Service  

@Service  
class ProductsPersistenceAdapter(  
    private val repository: ProductsRepository,  
) : ProductsPersistencePort {  
    override fun findAllProducts(): List<Product> =  
        repository.findAll().toDomains()  

    override fun findProductById(id: Long): Product? =  
        repository.findByIdOrNull(id)?.let { return it.toDomain() }  

    override fun saveProduct(product: Product): Product =  
        repository.save(product.toEntity()).toDomain()  
}

Kapitel 7: Die Application

classDiagram
    class Application {
        <<SpringBootApplication>>
        -ProductsPersistencePort persistencePort
        +findAllProducts() List~Product~
        +findProductById(Long id) Product?
        +createProduct(Product product) Product
        +applyDiscountToProduct(Long id, Double discount) Product?
        +main(String[] args)$
    }

    class ProductsEndpointPort {
        <<interface / from domain>>
    }

    class ProductsPersistencePort {
        <<interface / from domain>>
    }

    class Product {
        <<data class / from domain>>
        +applyDiscount(Double discount)
    }

    class ProductsEndpointAdapter {
        <<RestController / from adapters:endpoint>>
        -ProductsEndpointPort port
    }

    class ProductsPersistenceAdapter {
        <<Service / from adapters:persistence>>
    }

    Application ..|> ProductsEndpointPort : implements (Driving Port)
    Application --> ProductsPersistencePort : uses (Driven Port)
    Application ..> Product : orchestrates domain logic
    ProductsEndpointAdapter --> ProductsEndpointPort : injects (Application)
    ProductsPersistenceAdapter ..|> ProductsPersistencePort : implements

classDiagram
    class Application {
        <<SpringBootApplication>>
        -ProductsPersistencePort persistencePort
        +findAllProducts() List~Product~
        +findProductById(Long id) Product?
        +createProduct(Product product) Product
        +applyDiscountToProduct(Long id, Double discount) Product?
        +main(String[] args)$
    }

    class ProductsEndpointPort {
        <<interface / from domain>>
    }

    class ProductsPersistencePort {
        <<interface / from domain>>
    }

    class Product {
        <<data class / from domain>>
        +applyDiscount(Double discount)
    }

    class ProductsEndpointAdapter {
        <<RestController / from adapters:endpoint>>
        -ProductsEndpointPort port
    }

    class ProductsPersistenceAdapter {
        <<Service / from adapters:persistence>>
    }

    Application ..|> ProductsEndpointPort : implements (Driving Port)
    Application --> ProductsPersistencePort : uses (Driven Port)
    Application ..> Product : orchestrates domain logic
    ProductsEndpointAdapter --> ProductsEndpointPort : injects (Application)
    ProductsPersistenceAdapter ..|> ProductsPersistencePort : implements

Das application-Modul fungiert als Klebstoff, der alle Komponenten zusammenhält. Hier werden die Abhängigkeiten zu allen anderen Modulen definiert, damit Spring Boot den Application Context vollständig aufbauen kann.

// application/build.gradle.kts

plugins {  
    id("application")  
    alias(libs.plugins.spring.boot)  
}  

dependencies {  
    implementation(project(":domain"))  
    implementation(libs.spring.boot)  
    implementation(project(":adapters:endpoint"))  
    implementation(project(":adapters:persistence"))  
    developmentOnly(libs.spring.boot.devtools)  
    annotationProcessor(libs.spring.boot.configuration)  
}

// application/build.gradle.kts

plugins {  
    id("application")  
    alias(libs.plugins.spring.boot)  
}  

dependencies {  
    implementation(project(":domain"))  
    implementation(libs.spring.boot)  
    implementation(project(":adapters:endpoint"))  
    implementation(project(":adapters:persistence"))  
    developmentOnly(libs.spring.boot.devtools)  
    annotationProcessor(libs.spring.boot.configuration)  
}

Die zentrale Klasse Application dient hierbei nicht nur als Startpunkt, sondern übernimmt in diesem Beispiel auch die Orchestrierung der Use Cases. Sie implementiert den ProductsEndpointPort (den Eingang zur Domäne) und nutzt den ProductsPersistencePort (den Ausgang zur Datenbank). Durch Dependency Injection wird die konkrete Implementierung des Persistenz-Adapters (ProductsPersistenceAdapter) zur Laufzeit bereitgestellt.

Diese Struktur ermöglicht es, dass die Domäne selbst frei von Framework-Code bleibt, während die Application-Klasse die Verbindung zwischen den abstrakten Ports der Domäne und den konkreten Adaptern herstellt.

// application/src/main/kotlin/consulting/atra/hexagon/Application.kt

package consulting.atra.hexagon  

import consulting.atra.hexagon.domain.Product  
import consulting.atra.hexagon.domain.ProductsEndpointPort  
import consulting.atra.hexagon.domain.ProductsPersistencePort  
import org.springframework.boot.autoconfigure.SpringBootApplication  
import org.springframework.boot.runApplication  

@SpringBootApplication  
class Application(  
    private val persistencePort: ProductsPersistencePort  
) : ProductsEndpointPort {  
    override fun findAllProducts(): List<Product> =  
        persistencePort.findAllProducts()  

    override fun findProductById(id: Long): Product? =  
        persistencePort.findProductById(id)  

    override fun createProduct(product: Product): Product =  
        persistencePort.saveProduct(product)  

    override fun applyDiscountToProduct(  
        id: Long,  
        discount: Double  
    ): Product? {  
        var product = persistencePort.findProductById(id)  
        if (product != null) {  
            product.applyDiscount(discount)  
            product = persistencePort.saveProduct(product)  
        }  
        return product  
    }  
}  

fun main(args: Array<String>) {  
    runApplication<Application>(*args)  
}

// application/src/main/kotlin/consulting/atra/hexagon/Application.kt

package consulting.atra.hexagon  

import consulting.atra.hexagon.domain.Product  
import consulting.atra.hexagon.domain.ProductsEndpointPort  
import consulting.atra.hexagon.domain.ProductsPersistencePort  
import org.springframework.boot.autoconfigure.SpringBootApplication  
import org.springframework.boot.runApplication  

@SpringBootApplication  
class Application(  
    private val persistencePort: ProductsPersistencePort  
) : ProductsEndpointPort {  
    override fun findAllProducts(): List<Product> =  
        persistencePort.findAllProducts()  

    override fun findProductById(id: Long): Product? =  
        persistencePort.findProductById(id)  

    override fun createProduct(product: Product): Product =  
        persistencePort.saveProduct(product)  

    override fun applyDiscountToProduct(  
        id: Long,  
        discount: Double  
    ): Product? {  
        var product = persistencePort.findProductById(id)  
        if (product != null) {  
            product.applyDiscount(discount)  
            product = persistencePort.saveProduct(product)  
        }  
        return product  
    }  
}  

fun main(args: Array<String>) {  
    runApplication<Application>(*args)  
}

Fazit

Die Transformation vom monolithischen Spring Starter Projekt zur hexagonalen Architektur ist vollzogen. Durch die Aufteilung in Module (domain, adapters, application) wurde eine klare Trennung der Verantwortlichkeiten erreicht.

Die Domäne ist nun das unabhängige Herzstück der Anwendung, frei von Framework-Abhängigkeiten und rein in Kotlin geschrieben. Externe Einflüsse wie REST-Schnittstellen oder Datenbanken wurden in separate Adapter ausgelagert, die über definierte Ports mit der Domäne kommunizieren.

Zwar erhöht sich durch die Modularisierung und die Einführung von Mapping-Schichten die anfängliche Komplexität und die Menge an Boilerplate-Code, jedoch wird dies durch eine signifikant verbesserte Testbarkeit, Wartbarkeit und Flexibilität aufgewogen. Technologien können einfacher ausgetauscht und die Geschäftslogik isoliert getestet werden, was langfristig zu einer robusteren Softwarearchitektur führt.

Daniel Schock

Senior Software Engineer

Daniel ist ein erfahrener Fullstack-Entwickler und DevOps-Spezialist mit einem klaren Schwerpunkt auf der Backend-Entwicklung mit Java und Kotlin. Seine Expertise wird durch praktische Erfahrung in der Frontend-Entwicklung mit Vue.js abgerundet. Er verfügt über umfassende Kenntnisse in der Konzeption von CI/CD-Pipelines sowie im Einsatz von Cloud-Technologien wie Kubernetes und AWS, die er erfolgreich in den Branchen Versicherung, Logistik und E-Commerce einsetzte. Daniel arbeitet bevorzugt in agilen Umgebungen und zeichnet sich durch seine analytische Denkweise und hohe Problemlösungskompetenz aus.

d.schock@atra.consulting    

Unter dem Motto »Embrace Change« fand die OOP 2026 vom 10. bis 13. Februar erstmals im MOC in München statt. Wir waren vor Ort und teilen unsere Eindrücke der besuchten Vorträge.

Nach 35 Jahren hat die OOP Konferenz [1] ihren angestammten Platz verlassen und ist in das MOC München umgezogen. Ein Wandel, der zum diesjährigen Motto »Embrace Change« passte, auch wenn die Konferenz auf uns in der neuen Umgebung etwas kleiner wirkte als in den Vorjahren. Trotz widriger Umstände – ein Streik legte am Mittwoch den Münchener ÖPNV weitgehend lahm – war die Anreise dank guter Parksituation am neuen Standort entspannt.

Inhaltlich war die diesjährige Ausgabe natürlich stark vom Thema Künstliche Intelligenz (KI) dominiert: Nahezu die Hälfte des Programms drehte sich direkt um AI, GenAI und Agentic Engineering. Aber auch die klassischen Themen wie Softwarearchitektur, Soziotechnische Systeme und 25 Jahre Agiles Manifest kamen nicht zu kurz – und waren an vielen Stellen von KI “durchzogen”.

Die Konferenz ist mit über 120 Fachvorträgen in thematische Tracks unterteilt, die das gesamte Spektrum der modernen Softwareentwicklung abdecken:

• Software Architecture – Building Software That Adapts: Strategien für flexible, zukunftsfähige Systemarchitekturen.
• Software Architecture – The Impact of Generative AI: Einfluss generativer KI auf Design-Paradigmen und Architekturprozesse.
• AI and the End of Business-as-Usual: Transformation von Geschäftsmodellen und Arbeitsprozessen durch KI.
• Product Ownership, User Experience & Requirement Engineering: Nutzerzentrierte Produktentwicklung und Anforderungsmanagement.
• Back to Basics of Design, Architecture, and Programming: Rückbesinnung auf fundamentale Prinzipien des Software-Handwerks.
• Domain-Driven Design (DDD): Beherrschung komplexer Fachdomänen durch kollaborative Modellierung.
• Platform Engineering: DevOps, thought further(?): Effizienzsteigerung durch interne Entwicklerplattformen und DevOps-Evolution.
• Legacy & Innovation: Modernisierung von Altsystemen bei gleichzeitiger Aufrechterhaltung der Innovationskraft.
• Testing & Quality: Qualitätssicherung, Test-Automatisierung und Validierung von KI-/Cloud-Systemen.
• Agility, Leadership & Social Integration: Führungskultur, psychologische Sicherheit und moderne Agilität.
• Emerging Changes: Externe Einflüsse wie Green IT, Nachhaltigkeitsgesetze und Regulatorik.

Die OOP2026 reflektiert „25 Jahre Agiles Manifest“ und hinterfragt, was nach der Agilität kommt. Die Eröffnungs-Keynote setzt sich kritisch mit der Vorherrschaft von US-Hyperscalern und politischen Einflüssen auf die IT-Infrastruktur auseinander und ist schon fast eine politische Ansage. Besonders hervorgehoben wird über alle Tracks der soziotechnische Ansatz – die Verbindung von Architektur, Teamkultur und Psychologie. Künstliche Intelligenz ist nicht mehr nur ein Trend-Thema, sondern zentraler Aspekt der OOP 2026. 

So nimmt das Thema KI/AI (inkl. GenAI und Agentic AI) etwa 30-40% des Gesamtprogramms ein. Es gibt einen dedizierten KI-Track („AI and the End of Business-as-Usual“), aber KI-Inhalte finden sich cross-funktional in fast allen anderen Tracks (z.B. KI in der Software-Architektur, KI-gestütztes Testing, Ethik der KI). Zentrale KI-Themen sind:

• Agentic Engineering: Der Übergang vom bloßen „Prompting“ zu autonomen KI-Agenten in der Entwicklung.
• GenAI-Ethik: Kritische Diskussion über die „ethische Nutzung“ und soziale Folgen (Vereinsamung in Teams durch KI-Automatisierung).
• KI-native Produktentwicklung: Wie Produkte von Grund auf neu gedacht werden müssen, wenn KI die Basis ist.
• EU AI Act: Regulatorische Anforderungen und deren Umsetzung in der Software-Architektur.

Keynote: Eine Unterschrift Trumps und US-Hyperscaler sind illegal

Sprecher: Max Schrems

Den Auftakt machte Max Schrems mit einer juristisch-technischen Realitätsprüfung, die es in sich hatte. Schrems, bekannt für seine erfolgreichen Klagen gegen Facebook, beleuchtete die massive Abhängigkeit europäischer Unternehmen von US-Cloud-Anbietern im Kontext der aktuellen geopolitischen Lage.

Sein Kernargument: Durch Gesetze wie FISA 702 sind US-Anbieter („Electronic Communication Service Provider“) verpflichtet, US-Behörden Zugriff auf Daten (“Foreign Intelligence Information«, also somit eigentlich alles) von Nicht-US-Bürgern zu gewähren – was im direkten Konflikt mit der DSGVO und der EU-Grundrechtecharta steht. Microsoft soll ihm zufolge im Schnitt die Daten von ca. 200.000 Accounts pro Halbjahr offenlegen. Da dies auch Firmenaccounts umfasst, sind so Millionen Anwender außerhalb der EU betroffen.

Und wie die gezeigte Seite aus Originalunterlagen der US-Regierung dazu eindrucksvoll (“Yahoo!, AOL, …”) dokumentiert, gilt dies auch schon seit mehr als 15 Jahren:

In gewissen Ländern wie bspw. Kuba und Nordkorea dürfen US-Tech-Dienste aufgrund entsprechender Vorgaben der US-Regierung derzeit schon nicht operieren. Außerdem werden Einzelpersonen regelmäßig durch die US-Regierung sanktioniert, siehe das Beispiel eines Richters des Internationalen Strafgerichtshofs, dessen sämtliche Konten bei US-Unternehmen wie Amazon, Airbnb oder PayPal von den Anbietern sofort geschlossen wurden [2]. Schrems stellte die berechtigte Frage, was nun mit Dänemark wegen Grönland passieren wird.

Er verdeutlichte darüber hinaus, dass eine einfache „Executive Order“ des US-Präsidenten ausreicht, um Datentransfers für illegal zu erklären, Sanktionen zu verhängen oder den USA weitergehenden Zugriff auf Daten von Nicht-US-Bürgern zu gewähren.

Hierbei lieferte er auch noch spannende Details zum Instrument “Executive Order”, welches sich wohl aufgrund der immer schwierigeren Gesetzgebungsverfahren mit dem Kongress schon seit Jahren zum Mittel der Wahl der US-Regierungen gemausert hat. Die Executive Order ist dabei kein Gesetz, sondern eine Dienstanweisung an Bundesbehörden. Sie kann bestehende Gesetze, die vom Kongress verabschiedet wurden, zwar nicht außer Kraft setzen oder umschreiben, durch geschickte Formulierung aber bspw. die Arbeit einer Behörde so einschränken, dass dies dem gleich kommt. Außerdem bestehen Möglichkeiten für den Präsidenten, die Inhalte von Executive Orders (und ähnlichen präsidialen Anweisungen) geheim zu halten. 

Besonders kritisch sah er die sogenannten „Supplementary Measures“ (wie Verschlüsselung) der Hyperscaler, die oft mehr Marketing als echter Schutz seien, solange der Anbieter selbst den Schlüssel hält oder durch US-Recht zur Herausgabe gezwungen werden kann. Mehr Details siehe bspw. auch hier [3]. 

Sein Fazit war ernüchternd, aber klar: Eine rechtlich saubere Trennung wäre zwar möglich, insofern die großen Player ihre europäischen Dependancen bspw. als reine Finanzbeteiligungen führen würden, was aber  bisher nicht konsequent umgesetzt wurde. Und da wir faktisch auch gar nicht wissen, welche Daten wirklich mitgelesen werden (Stichwort: geheime Executive Order), wäre es auch so oder so skeptisch zu bewerten. Für uns als Software Architekten bedeutet dies: Das Risiko ist real, „Compliance“ ist mehr als nur Papierkram und Digitale Souveränität wird und muss unseren Arbeitsalltag beherrschen.

Lean Compliance as Strategic Asset in Agile Organizations

Sprecher: Felix Rüssel, Erika Schüttfort

Passend zum Thema Regulierung zeigte dieser Vortrag einen pragmatischen Weg aus der „Death by Checklists“-Falle, die wir in Europa mit im Schnitt einer neuen Regulierung alle drei Stunden schon lange erreicht haben. Und sich durch immer neue Anforderungen (Lieferkettensorgfaltspflichtengesetz, Digital Operational Resilience Act, …) auch auf unsere Arbeit als Softwarearchitekten und Produktentwickler niederschlägt:

Die Referenten legten dar, dass viele Unternehmen Compliance fälschlicherweise als nachgelagerte Kontrollinstanz missverstehen. Stattdessen sei Compliance als integraler, wertschöpfender Baustein innerhalb des Wertstroms zu betrachten, dessen Fehlplanung oder Engpässe ein fundamentales Fluss-Problem („Flow“) darstellen.

Statt Compliance als nachgelagerten Bremsklotz zu behandeln, sollte sie als „Lean Compliance“ integraler Bestandteil des Entwicklungsprozesses sein (“Shift Left”). Das Ziel ist eine echte Zusammenarbeit zwischen „Makers“ (Entwicklern) und „Checkers“ (Compliance Officers), statt eines Gegeneinanders. 

Besonders interessant war der Ansatz der „Minimum Viable Compliance“ (MVC) – also Compliance iterativ und parallel zum Produkt zu entwickeln, statt am Ende vor einem Berg an Anforderungen zu stehen.

Die Redner adaptieren hierbei Kernprinzipien agiler Frameworks wie Scrum und Kanban für den Compliance-Sektor. Anstatt als isolierte Prüfinstanz zu agieren, integriert sich die Compliance-Funktion unmittelbar in cross-funktionale Produktteams, um regulatorische Anforderungen als kontinuierlichen Teil des Entwicklungsprozesses zu begreifen.

Gerade in Deutschland ist die Klage über eine vermeintliche Überregulierung allgegenwärtig. Die Referenten schlossen ihren Vortrag jedoch mit einem pointierten Gegenentwurf ab: Nicht die Menge der Regulierung sei das primäre Hindernis, sondern deren ineffiziente Einbindung in die Wertschöpfungskette:

»Organisationen scheitern selten an der Regulierung selbst, sondern daran, dass ihr Betriebsmodell diese nicht absorbieren kann.«

Strategien für die Analyse großer Softwaresysteme mit Sprachmodellen

Sprecher: Michael Stal (Principal Key Expert Engineer, Siemens AG)

Michael Stal, eine der zentralen Figuren der OOP-Konferenz (Conference Chair, regelmäßiger Sprecher, Autor zahlreicher Fachpublikationen sowie Chefredakteur JavaSPEKTRUM) gab einen tiefen Einblick in das Projekt „SARA“ (Siemens Architecture Review Agent), ein Versuch, die millionenschweren Codebasen des Siemens-Konzerns mittels LLMs zu analysieren. Plakatives Ziel ist dabei, z.B. dem Software-Korpus des ICE die Frage stellen zu können, warum eine spezielle Baureihe des ICE unter gewissen Umständen nicht bremst. Hierzu haben sie ein komplexes System aufgesetzt, welches sowohl moderne KI-Ansätze als auch klassische Code-Analyse-Tools verbindet.

Der Vortrag war dabei auch erfrischend ehrlich bezüglich der Grenzen aktueller KI-Modelle. Stal zeigte auf, dass LLMs zwar stark im Pattern-Matching sind, ihnen aber oft das Verständnis für den zeitlichen Verlauf (Code-Historie) und den Projektkontext fehlt. Um Halluzinationen und Kontext-Probleme in den Griff zu bekommen, setzten sie auf fortgeschrittene Prompting-Strategien wie „Chain of Thought“ und Multi-Agenten-Systeme, bei denen ein Agent Lösungen vorschlägt und ein anderer (Critique Agent) diese prüft – ein sogenannter Adversarial Approach.

Vom Engineering-Standpunkt betrachtet, hat uns das Vorhaben hier umgehauen, da wurde modernste Technologie intelligent verbaut, um die Komplexität, die vermutlich tausende Entwickler und Architekten über Jahrzehnte geschaffen haben, zukünftig noch beherrschbar zu halten. Unsere Erkenntnis hier war jedoch auf unsere Nachfrage auch wirtschaftlicher Natur: Mit initialen Entwicklungskosten von rund 1,5 Millionen Euro und hohen Betriebskosten für private Cloud-Instanzen und Betriebsaufwänden für die durchaus komplexe Infrastruktur ist der Return on Invest (ROI) solcher Eigenentwicklungen noch nicht abschließend geklärt. Es bleibt der Eindruck: Man hat es gebaut, weil man es sich als Konzern leisten kann, aber der breite Nutzen muss sich erst noch beweisen.

Wie die Natur Probleme löst – und was IT-Projekte daraus lernen können

Sprecherin: Anna Melbinger

Dr. Anna Melbinger ist promovierte Physikerin, die nach mehrjähriger internationaler Forschungstätigkeit im Bereich der theoretischen und biologischen Physik in die Beratung wechselte, wo sie aktuell Transformations- und IT-Strategieprojekte leitet.

Ihr Vortrag, der biologische Strategien auf IT-Herausforderungen übertrug, war für uns einer der Höhepunkte der diesjährigen Konferenz – auch wenn keine Keynote. Die Natur, Meisterin im Schaffen langlebiger, komplexer Systeme, liefert ihr zufolge „Vorlagen“ und Hilfestellungen für unsere alltäglichen IT-Probleme.

Dabei optimiert die Natur nicht auf Effizienz, sondern auf Robustheit – ein Prinzip, das wir in der Softwarearchitektur oft vernachlässigen, sind doch gerade aktuell wieder Produktivität und Effizienz präsenter denn je.

Spannend war der Vergleich mit Bakterien (Chemotaxis) und Motten (Infotaxis), die Ziele nicht auf direktem Weg, sondern durch „Run-and-Tumble“ oder das Sammeln von Informationen erreichen. Für uns bedeutet das: In unsicheren Projektumgebungen ist es oft besser, Entscheidungspunkte zu setzen und sich an der Entwicklung von Kennzahlen (bspw. einem Abwärtstrend bei den Bugs) statt stur Meilensteine abzuarbeiten und absoluten Kennzahlen hinterherzurennen.

Eine wichtige Erkenntnis: Evolution passiert am Engpass und dementsprechend ist auch eine Entlastung am Engpass blinder Optimierung überlegen. Die Rednerin brachte hier das Beispiel der Laktose-Toleranz, welche in nördlichen Ländern aufgrund des veränderten Nahrungsangebots zu einem Überlebensvorteil geführt hat.

Auch das Konzept, dass Innovation Vielfalt (wie bei T-Zellen) und nicht vorzeitige Fokussierung benötigt, ist ein starkes Plädoyer für diverse Teams und Lösungsansätze, offenes Brainstroming und Design-Thinking-Ansätze.

Die Evolution, ein fundamentaler Prozess in der Natur, bewältigt die Herausforderungen der Anpassung und Optimierung durch das gnadenlose Prinzip des „Survival of the fittest“, sprich das Aussterben der weniger geeigneten. Ein solches Vorgehen ist in IT-Projekten, wo Zeit, Ressourcen und der Erfolg des Projekts auf dem Spiel stehen, weder wünschenswert noch praktikabel. Die „natürliche Auslese“, bei der ungeeignete Elemente erst in der späten Phase oder nach dem Scheitern des Gesamtprojekts identifiziert werden, ist ein kostspieliges und riskantes Unterfangen.

Die zentrale Herausforderung in IT-Projekten lautet daher: Wie können wir dieses natürliche Prinzip umkehren? Wie können wir proaktiv und im Voraus erkennen, welche Teile unseres Projekts – seien es Code-Architekturen, Prozesse oder Anforderungen – nicht „fit“ (geeignet, nachhaltig, wartbar) sind, bevor sie Schaden anrichten oder das Projekt in eine Sackgasse führen?

Hierzu lieferte die Rednerin keinen Blueprint, unserer Erkenntnis nach bieten agile Prinzipien aber einen wesentlichen Lösungsansatz. Sie bieten Methoden und Rahmenwerke, um das Unsichtbare sichtbar zu machen. Eine Kultur der kontinuierlichen Inspektion und Adaption zwingt durch kurze Iterationen (Sprints in Scrum) oder den ständigen Fluss in Kanban das Team, regelmäßig innezuhalten (z.B. in Retrospektiven) und kritisch zu hinterfragen, was funktioniert und was nicht. Dies ist die künstliche, menschlich gesteuerte Alternative zur „natürlichen Auslese“: Wir erkennen die Mängel, bevor das „Aussterben“ (das Scheitern des Projekts) droht, und korrigieren den Kurs.

Keynote: State of Play: KI-unterstütztes Programmieren

Sprecherin: Birgitta Böckeler (Thoughtworks)

Birgitta Böckeler lieferte einen sehr fundierten Überblick über den aktuellen Stand von KI in der Softwareentwicklung. Wir bewegen uns ihr zufolge weg vom reinen „Autocomplete on Steroids“ hin zu „Agentic Engineering“ und komplexen Workflows.

Besonders wichtig erschien uns der Hinweis auf das „Context Engineering“: Der Erfolg von KI-Tools hängt entscheidend davon ab, wie effektiv der Kontext – also Regeln, benötigte Fähigkeiten und Schnittstellen – gemanagt und der KI bereitgestellt wird. Man könnte dies als eine Art „Prompt Engineering on steroids“ oder „RAG on steroids“ bezeichnen. Im Kern geht es dabei nach wie vor darum, ein großes „Standard“-Sprachmodell, das die wenigsten aus Kostengründen selbst trainieren können, mit den notwendigen Informationen zu versorgen – entweder direkt über den Prompt oder „intelligent“ aus angeschlossenen Drittsystemen. 

Wobei die auch hier von der Rednerin u.a. referenzierte Agents.md nicht das Allheilmittel ist, mit dem sie derzeit durch die entsprechenden Fachmedien geht. Eine aktuelle Studie [4] fand dazu heraus: 

»Across multiple coding agents and LLMs, we find that context files tend to reduce task success rates compared to providing no repository context, while also increasing inference cost by over 20%.«

Die Rednerin war ebenso wie wir davon überzeugt, dass lokal betriebene, kleine Modelle mittelfristig aus Komplexitäts- und Performancegründen aussterben werden. So sind ihrer Einschätzung nach selbst die guten kleinen Modelle 8-12 mal langsamer als die großen:

Gleichzeitig warnte sie vor den Kosten („The Honeymoon is over“) und Sicherheitsrisiken wie Prompt Injection. Ihr Rat: Kenne dein Werkzeug und nutze es, auch wenn du skeptisch bist – denn KI wird die Art, wie wir Software bauen, fundamental verändern, auch wenn Halluzinationen ein “Feature” und kein Bug bleiben.

Im Vortrag wurden auch einige aufschlussreiche Zahlen zu den Kosten von KI in der Entwicklung präsentiert, die in all dem Marketing-Hype (“Wir brauchen dank KI keine Entwickler mehr”) gerade untergehen. Während die KI-Generierung von 100 Zeilen Code Anfang 2024 lediglich 12 Cents kostete, stiegen diese Kosten bis zum Sommer 2025 auf 2,5 $ – in anderthalb Jahren also um den Faktor 21! Bei intensiver Nutzung in der Entwicklung – man darf nicht außer acht lassen, dass all die Agenten, die da gerade am Werk sind, extrem Token-hungrig sind, können die KI-Kosten schnell auf jährlich rund 90.000 $ steigen. Ein Betrag, für den man wiederum auch einen Entwickler einstellen könnte…

Und obwohl KI die Code-Erstellung beschleunigen mag, bleiben die Ergebnisse noch aus. So kommt ein Working Paper der Harvard University vom 7. Januar 2026 [5] bspw. zu folgender Erkenntnis:

»Generative AI tools like Copilot and Cursor lead to moderate [~8 %], but not transformational, improvements in engineers’ productivity […and] does not translate to effects on downstream outcomes.«

Ein kritischer Punkt ist und bleibt der Mensch als limitierender Faktor bei der Verwaltung der Vielzahl von KI-Agenten. Die wesentlichen Schritte der Softwareentwicklung bleiben der Rednerin zufolge weiterhin in menschlicher Hand, nämlich die Spezifikation (Klärung der Anforderungen: „Was will ich?“) und die Verifizierung (Überprüfung des Ergebnisses: „Ist es das, was ich will?“).

Missverständnisse zu Softwarearchitektur

Sprecherin: Carola Lilienthal

Carola Lilienthal räumte gewohnt souverän mit gängigen Mythen der Softwarearchitektur auf. Basierend auf ihrer Analyse hunderter Softwaresysteme zeigte sie, warum Sätze wie „Wir machen Microservices, also brauchen wir keine Architektur mehr“ oder „Neubau ist besser als Refactoring“ gefährliche Trugschlüsse sind.

Ein Dauerbrenner für die Praxis der Softwareentwicklung und der Rednerin (und unserer Einschätzung) zufolge das Fundament modularer und wartbarer Architekturen: Die klare Unterscheidung und konsequente Anwendung hoher Kohäsion (engl. High Cohesion) innerhalb von Modulen und von loser Kopplung (engl. Loose Coupling) zwischen Modulen.

Hohe Kohäsion bedeutet, dass die Elemente innerhalb eines Moduls (z.B. Klassen, Methoden oder Funktionen) eine starke thematische und funktionale Zusammengehörigkeit aufweisen. Sie arbeiten eng zusammen, um eine einzige, klar definierte Verantwortung zu erfüllen (dem Single Responsibility Principle folgend). Module mit hoher Kohäsion sind leichter zu verstehen, zu testen und zu warten, da Änderungen an einer Verantwortung meist nur dieses eine Modul betreffen.

Lose Kopplung hingegen beschreibt das Ideal minimaler, wohl-definierter Abhängigkeiten zwischen verschiedenen Modulen. Module sollten so wenig wie möglich über die internen Details anderer Module wissen. Änderungen im Inneren eines Moduls sollen idealerweise keine oder nur minimale Auswirkungen auf andere, davon abhängige Module haben (lose Kopplung). Dies wird oft durch die Verwendung von klaren Schnittstellen (Interfaces), Abstraktionen und Dependency Injection erreicht.

Eine zentrale Gefahr und eine ständige Herausforderung in der Architektur ist die Entstehung zyklischer Abhängigkeiten (engl. Circular Dependencies). Hierbei hängt Modul A von Modul B ab, und Modul B hängt gleichzeitig von Modul A ab. Solche Zyklen bilden „Super-Module“ oder große, unflexible Abhängigkeitsringe, die die Vorteile von Modularität vollständig untergraben.

Die Warnung der Rednerin vor zyklischen Abhängigkeiten ist dabei besonders vehement, da sie auch durch Interfaces nicht verschwinden. Ein Interface kann zwar die Art der Abhängigkeit auf eine Abstraktionsebene heben und die Kopplung lockern, aber es löst den zyklischen Verweis selbst nicht auf. Wenn Modul A eine Schnittstelle I definiert, die Modul B implementiert, und Modul B dann wiederum direkt oder indirekt Modul A importiert, besteht der Zyklus weiterhin, was die Testbarkeit, die Wiederverwendbarkeit und die Deployment-Flexibilität massiv einschränkt. Die saubere Auflösung solcher Zyklen erfordert oft eine Umstrukturierung der Module oder die Einführung einer weiteren Abstraktionsebene (z.B. ein drittes Modul, das die Abhängigkeiten orchestriert).

Obwohl der Quellcode die „Wahrheit“ darstellt und KI uns immer besser beim Verständnis desselben unterstützt, bleibt eine grundlegende Dokumentation von Softwaresystemen unverzichtbar. Denn die Beweggründe für bestimmte architektonische Entscheidungen kann selbst eine KI nicht einfach aus dem Code ableiten, wie auch Michael Stal in seinem Vortrag eindrucksvoll verdeutlichte.

Sehr gut hat uns die kompakte Zusammenfassung des arc42-Ansatzes zur Architekturdokumentation [6] der Rednerin gefallen. Es gelang ihr, die zentralen Konzepte und die Struktur, die dieses Open-Source-Framework für eine effektive und verständliche Dokumentation von Software-Architekturen bietet, auf den Punkt zu bringen, ohne dabei wesentliche Details zu übergehen. 

Ein solider, fast zeitloser Vortrag, der daran erinnerte, dass die handwerklichen Grundlagen auch im KI-Zeitalter unverzichtbar bleiben.

Was Craftsmanship ausmacht

Sprecher: Marco Achtziger

Ergänzend wurden in diesem Vortrag Einblicke in die Implementierung von „Craftsmanship“-Programmen, konkret im Testumfeld von Siemens, gewährt. Die zentrale Erkenntnis war, dass exzellentes Handwerk nicht hierarchisch verordnet werden kann. Stattdessen erfordert es einen kulturellen Wandel, der sich an Daniel Pinks Werk Drive [7] orientiert. Dieser Wandel basiert auf den drei Säulen intrinsischer Motivation – Autonomie (Autonomy), Beherrschung des Fachgebiets (Mastery) und Sinnhaftigkeit (Purpose) –, die essenziell sind, um Leistung und Zufriedenheit in der modernen Wissensarbeit zu steigern.

Der Redner gab dabei auch einen interessanten Einblick in die Software Craftsmanship Bewegung, beginnend in den 1990ern mit Extreme Programming, über Robert Martins  Clean Code(r) und das “Manifesto for Software Craftsmanship“ im Jahr 2009 [8]:

Eines von Steven Jobs berühmten Zitaten bildete einen guten Abschluss zu dem Vortrag:

»When you’re a carpenter making a beautiful chest of drawers, you’re not going to use a piece of plywood on the back, even though it faces the wall and nobody will ever see it. You’ll know it’s there, so you’re going to use a beautiful piece of wood on the back. For you to sleep well at night, the aesthetic, the quality, has to be carried all the way through.«

Unsere Einschätzung

Die OOP 2026 hat gezeigt, dass die Branche in Bewegung ist. Der Umzug in das MOC hat der Veranstaltung durch die bessere Verkehrsanbindung und die weiterläufigeren Räumlichkeiten gut getan, auch wenn sie etwas kompakter wirkte. Inhaltlich war die Dominanz von KI allgegenwärtig – nicht mehr als Hype, sondern in der Phase der konkreten, teils ernüchternden, teils hoffnungsvollen Anwendung (Agentic AI, RAG) – wo man das Thema in Gartners Hype-Cycle [9] aktuell verortet, mag dabei jeder für sich entscheiden:

Gleichzeitig war spürbar, dass die klassischen Tugenden – saubere Architektur, soziotechnische Gestaltung und solides Handwerk – nicht an Bedeutung verlieren, sondern gerade durch die KI-Unterstützung noch wichtiger werden, um die entstehende Komplexität beherrschbar zu halten.

Quellenangaben

Die Informationen basieren auf dem Besuch der OOP 2026 sowie den bereitgestellten Unterlagen und Vortragsbeschreibungen der Konferenz.

[1]: https://www.oop-konferenz.de/de
[2]: https://www.heise.de/news/Wie-ein-franzoesischer-Richter-von-den-USA-digital-abgeklemmt-wurde-11087453.html 
[3]: https://www.heise.de/news/Nicht-souveraen-Microsoft-kann-Sicherheit-von-EU-Daten-nicht-garantieren-10494684.html 
[4]: https://arxiv.org/abs/2602.11988
[5]: https://fion.ac/jellyfish.pdf
[6]: https://arc42.de/
[7]: https://en.wikipedia.org/wiki/Drive:_The_Surprising_Truth_About_What_Motivates_Us
[8]: https://manifesto.softwarecraftsmanship.org/
[9]: https://de.wikipedia.org/wiki/Hype-Zyklus 

Michael Schwarze

Geschäftsführer

Michael ist ein erfahrener Softwareentwickler, -architekt und -manager mit über 30 Jahren Erfahrung in der Technologiebranche. Er hat sowohl in Startups als auch Konzernen auf Anwender- als auch Entwicklungs- und Beratungsseite gearbeitet.  Coden ist für ihn nicht nur Beruf, sondern Leidenschaft, am liebsten mit dynamisch-typisierten Sprachen wie Ruby. Neben der Entwicklung langlebiger Softwaresysteme liegt ihm auch die Verbesserung des Managements in der Softwareentwicklung am Herzen. Wenn er nicht gerade mit seiner Familie und seinen zwei Kindern beschäftigt ist, findet man ihn in den Bergen, beim Joggen oder anderen sportlichen Aktivitäten.

m.schwarze@atra.consulting    

• LinkedIn

Umso erstaunter war ich, als mir kürzlich in einem ruhigen Moment auffiel, dass ich mich selbst im Arbeitsalltag erstaunlich selten daran halte. Und schlimmer noch: dass ich ziemlich gut darin geworden bin, mir das auch noch schönzureden.

Eisenhower ist aus meiner Sicht weiterhin ein sinnvolles Werkzeug – das ist mir wichtig vorwegzuschicken. Gleichzeitig stößt dieses Zeitmanagement-Modell aus der Mitte des 20. Jahrhunderts – entwickelt von einem US-General und späteren Präsidenten – im Arbeitsalltag moderner Wissensarbeiter erstaunlich schnell an seine Grenzen.

Dafür gibt es mehrere Gründe.

Kognitive Überlastung: Wenn zu viele Reize um Aufmerksamkeit konkurrieren

Wissensarbeiter – egal ob Fachspezialisten, Berater oder Entscheider – leiden heute weniger an fehlender Priorisierung als an kognitiver Überlastung. Die ständige Notwendigkeit, zwischen konzentrierter Arbeit an komplexen Fragestellungen und reaktiver Kommunikation zu wechseln, erzeugt Kontextwechselkosten (siehe auch [1]), die Fokus, Entscheidungsqualität und letztlich auch die eigene Zufriedenheit spürbar beeinträchtigen.

Die Eisenhower-Matrix verspricht an dieser Stelle eigentlich Orientierung, scheitert jedoch häufig an der psychologischen Realität der Illusion of Urgency [2]: Aufgaben fühlen sich dringend an, erzeugen Handlungsdruck und verlangen Aufmerksamkeit – ohne deshalb, um in der Sprache von Eisenhower zu bleiben, automatisch auch wichtig oder tatsächlich dringend zu sein.

Für mich hat sich daraus eine einfache, bewusst pragmatische Regel ergeben: Aufgaben, die sich in weniger als fünf Minuten erledigen lassen, versuche ich unmittelbar abzuschließen. Nicht aus Effizienzgründen im klassischen Sinne, sondern um kognitive Last zu reduzieren. Jede nicht beantwortete Rückfrage, jede angefangene, aber nicht abgeschlossene Kleinigkeit bleibt im Kopf präsent – und konkurriert dort mit eigentlich wichtigeren Themen um Aufmerksamkeit.

Das Problem: In meinem hochfragmentierten Arbeitsalltag gibt es überraschend viele „kurze Anfragen“. Und so schlägt die Fünf-Minuten-Regel bei mir erstaunlich oft Eisenhower.

Und ja, ich weiß: Man muss Mails und Chatnachrichten nicht sofort lesen. In der Theorie leuchtet mir das vollkommen ein. In der Praxis stressen mich 13 ungelesene Teams-Nachrichten jedoch zuverlässig. Disziplinierte Zeitfenster für Mail- und Chatkommunikation funktionieren für manche hervorragend. Für mich nicht. Und so stößt auch Eisenhower an seine Grenzen.

Kognitive Last der Organisation: Wenn zu viele Themen gleichzeitig offen sind

Nun ist kognitive (Über-)Last kein individuelles Versagen. Sie ist in vielen Fällen ein übergreifendes organisatorisches Problem. Organisationen arbeiten selten an einem Thema zur gleichen Zeit. Sie arbeiten an sehr vielen. Projekte, Initiativen, Abstimmungen, Eskalationen, strategische Themen und operative Kleinigkeiten laufen parallel – oft über Monate oder sogar Jahre. Jeder offene Vorgang erzeugt kognitive Last. Nicht nur bei Einzelpersonen, sondern im System insgesamt: in Meetings, Statusrunden, Entscheidungsprozessen oder auch nur, weil ich diese eine nervige Aufgabe nun schon zum dritten Mal in die Folgewoche verschiebe.

Diese systemische kognitive Last entsteht unabhängig davon, wie dringend oder wichtig ein einzelnes Thema gerade ist. Allein die Tatsache, dass etwas „noch offen“ ist, bindet Aufmerksamkeit. Ein psychologisches Fundament dieser Beobachtung liefert übrigens der Zeigarnik-Effekt, der besagt, dass uns unterbrochene, unerledigte Aufgaben kognitiv stärker beschäftigen als abgeschlossene [4]. Das kostet Energie – selbst dann, wenn faktisch gerade niemand daran arbeitet.

Ein besonders plastisches Beispiel dafür habe ich im behördlichen Umfeld erlebt. Eine Broschüre sollte aktualisiert werden – kein besonders dringendes Thema, von mittlerer Wichtigkeit. Der erste Entwurf war schnell erstellt. Danach passierte lange Zeit: nichts. Aufgrund interner Prozesse mussten verschiedene Einheiten involviert werden, zwischen den einzelnen Abstimmungen lagen jeweils mehrere Wochen.

Das Ergebnis? Ein Prozess über 20 Monate. Durch unzählige Abstimmungsrunden und Liegezeiten musste sich jeder Beteiligte in jedem Termin neu eindenken („Wo standen wir nochmal?“). Am Ende wurde konservativ geschätzt mindestens das Zehnfache der eigentlichen Arbeitszeit investiert, nur weil das Thema immer wieder liegen blieb. Ein klassisches Beispiel dafür, wie „nicht dringende“ Themen durch reinen Zeitverzug zu hocheffizienten Ressourcenfressern mutieren.

Die Eisenhower-Matrix betrachtet Aufgaben isoliert. Sie hilft dabei, einzelne To-dos zu priorisieren. Was sie jedoch systematisch ausblendet, ist die kumulative Wirkung vieler paralleler, offener Themen auf eine Organisation.

In der Praxis ist es oft nicht das einzelne wichtige oder dringende Thema, das überlastet – sondern die schiere Anzahl an offenen Baustellen. Aus einer Lean-Perspektive ist es deshalb sinnvoll, die Anzahl gleichzeitig offener Themen möglichst gering zu halten. Nicht nur, um schneller zu werden, sondern um arbeitsfähig zu bleiben.

Genau hier beginnt ein Aspekt, den Eisenhower nur unzureichend adressiert: Offene Themen sind nicht neutral. Sie sind nicht einfach „noch nicht dran“. Sie erzeugen Kosten – allein durch ihr Liegenlassen.

Cost of Delay: Wenn Liegenlassen teuer wird

Wenn man genau hinschaut, habe ich im obigen Behördenbeispiel bereits ein Konzept verwendet, ohne es zu benennen: Cost of Delay.

Nicht die (gefühlte und meist sehr subjektive) Wichtigkeit einer Aufgabe entscheidet über ihre Priorität, sondern die Kosten, die entstehen, wenn sie nicht umgesetzt wird. Diese Kosten sind oft nicht sichtbar – aber sie sind real.

Ein einfaches Beispiel: Ein kurzes Debriefing zu einem Konferenzbesuch an Kollegen zu schicken, ist selten dringend und meist auch nicht besonders wichtig. Während der Zugfahrt nach Hause ist das in wenigen Minuten erledigt. Zwei Wochen später brauche ich dafür schon deutlich länger. Zwei Monate später muss ich anhand meiner Notizen rekonstruieren, was ich eigentlich mitteilen wollte.

Die Aufgabe ist dieselbe geblieben – der Aufwand nicht. Die Verzögerung hat hier keinen inhaltlichen Mehrwert erzeugt, sondern ausschließlich zusätzliche Arbeit. Genau das beschreibt Cost of Delay.

In Organisationen wirkt dieser Effekt noch stärker. Der eigentliche Cost of Delay entsteht häufig nicht durch fehlende Umsetzung, sondern durch das Wiederanlaufen: sich erneut einlesen, Kontexte rekonstruieren, Entscheidungen erklären, Abhängigkeiten neu klären. Je länger ein Thema liegt, desto höher werden diese Reibungsverluste. Besonders schön wird es dann, wenn Nachfragen nach dem Stand einer Aufgabe und ein oder zwei Feedbackschleifen in Summe bereits mehr Zeit kosten als die eigentliche Erledigung.

Eisenhower hilft dabei zu entscheiden, was wichtig und dringend ist. Cost of Delay macht sichtbar, was es kostet, nichts zu entscheiden – und Themen immer wieder liegen zu lassen.

Mir ist bewusst, dass Cost of Delay ein abstrakter Begriff bleibt. Mir hilft dieser Perspektivwechsel jedoch sehr, meine Arbeitsprioritäten besser zu setzen. Übliche Dimensionen, die meinen höchst persönlichen Cost of Delay ausmachen, sind:

• der erwartete Mehrwert des Arbeitspakets (strategisch, operativ oder risikoseitig)
• Effizienz- und Reibungsverluste über die Zeit (Wiederanlauf, Abstimmung, Kontextverlust)
• die Möglichkeit, Themen sauber abzuschließen und damit kognitive Last zu reduzieren
• Lernen und Wissensgewinn – oder dessen Verzögerung

Ob ich eine Aufgabe selbst erledige oder delegiere, beantwortet Cost of Delay allerdings nicht. Aber dazu kommen wir im kommenden Abschnitt.

Verteilte Verantwortung: Wenn klassische Delegation an Grenzen stößt

Die Eisenhower-Matrix ist in einer Welt klarer Hierarchien entstanden. Aufgaben werden priorisiert, erledigt oder delegiert. Delegation setzt dabei etwas voraus, das lange selbstverständlich war: eine eindeutige hierarchische Ordnung mit klarer Weisungsbefugnis.

In der Sprache von Reinventing Organizations [5] würde man sagen: Eisenhower passt hervorragend zu bernsteinfarbenen, stark hierarchischen Organisationen. Führung bedeutet dort, Entscheidungen zu treffen und Aufgaben weiterzugeben.

Viele Organisationen funktionieren heute jedoch anders. Wir sprechen über flache Hierarchien, selbstorganisierte Teams, laterale Führung und Servant Leadership. Verantwortung liegt nicht mehr ausschließlich bei einzelnen Rollen, sondern verteilt sich auf Teams. Entscheidungen werden gemeinsam getroffen, Aufgaben gemeinsam getragen.

In solchen Strukturen wird Delegation unscharf. An wen delegiere ich, wenn Verantwortung im Team liegt? Was bedeutet „abgeben“, wenn ich fachlich gar nicht weisungsbefugt bin? Und was passiert, wenn Delegation nicht als Entlastung, sondern als Abschieben wahrgenommen wird?

Gleichzeitig verstehen sich viele Organisationen zunehmend als lernende Systeme. Aufgaben sind nicht nur Mittel zur Zielerreichung, sondern auch Gelegenheiten zur Entwicklung. Konzepte wie Management 3.0 [6] betonen genau diesen Aspekt: Arbeit dient nicht nur der Effizienz, sondern auch dem Lernen, der Motivation und dem Kompetenzaufbau von Mitarbeitern.

Damit wird Delegation zu einer Führungsentscheidung mit mehreren Dimensionen. Nicht jede Aufgabe, die delegierbar wäre, sollte delegiert werden. Und nicht jede Aufgabe, die belastet, lässt sich sinnvoll abgeben. Eisenhower gibt darauf keine Antworten – weil er diese Organisationslogik schlicht nicht kennt.

Fazit: Eisenhower reicht nicht mehr – aber er bleibt hilfreich

Die Eisenhower-Matrix ist kein schlechtes Werkzeug. Sie hilft, innezuhalten, Aufgaben bewusst zu betrachten und sich nicht von jeder Dringlichkeit treiben zu lassen. Das allein ist viel wert.

In meinem Arbeitsalltag reicht sie jedoch nicht mehr aus. Kognitive Überlastung, systemische Reibung, Cost of Delay und veränderte Organisationsformen lassen sich nicht sauber in vier Quadranten pressen. Dafür sind moderne Wissensorganisationen zu komplex – und Arbeit zu stark von Kontext, Abhängigkeiten und Lernen geprägt.

Was mir heute hilft, ist kein Ersatz für Eisenhower, sondern eine Ergänzung: der bewusste Blick auf Liegezeiten, auf kognitive Last – und auf die Frage, was es mich und die Organisation kostet, Dinge nicht zu entscheiden.

Eisenhower hilft mir weiterhin bei der Orientierung. Die eigentliche Priorisierung entsteht jedoch erst im Zusammenspiel aus Kontext, Verantwortung und Cost of Delay. Am Ende bleibt die Erkenntnis: Ein Werkzeug ist eben nur ein Werkzeug. Mit einem Hammer lässt sich vieles erledigen – aber nicht alles im modernen Arbeitsalltag ist ein Nagel.

Referenzen

[1] Multitasking: Switching Costs – https://www.apa.org/topics/research/multitasking 
[2] The Illusion of Urgency –  https://pmc.ncbi.nlm.nih.gov/articles/PMC10159458/ 
[3] Mintzberg, H. (1973). The nature of managerial work.
[4] Zeigarnik-Effekt – https://de.wikipedia.org/wiki/Zeigarnik-Effekt 
[5] Reinventing Organisations – https://www.reinventingorganizations.com/ 
[6] Management 3.0 – https://management30.com/ 

Daniel Wochnik

Geschäftsbereichsleitung »Finanzdienstleistungen«

Daniel ist seit 2017 in der IT-Branche aktiv und bringt seine umfassende Erfahrung als Senior Managing Consultant und Geschäftsbereichsleiter für Finanzdienstleistungen bei atra.consulting ein. Besonders begeistert ihn das Zusammenspiel technischer, methodischer und organisatorischer Aspekte. Als leidenschaftlicher Läufer und bekennender 1. FC Köln-Fan hat er seine Leidensfähigkeit auch privat mehrfach unter Beweis gestellt. Seine Kunden unterstützt er als Softwarearchitekt, agiler Coach und Berater bei der nachhaltigen und zielgerichteten Umsetzung von Entwicklungsprojekten.

d.wochnik@atra.consulting    

• LinkedIn

Die Webentwicklung verändert sich rasant – aktuell vor allem durch neue Frontend-Paradigmen und den zunehmenden Einsatz von AI-gestütztem Coding. Genau deshalb war die c’t webdev conference Mitte November im KOMED im MediaPark in Köln für mich mehr als nur ein Pflichttermin.

Zwei Tage lang trafen sich dort Frontend-Entwickler:innen, die sich intensiv mit Themen wie UI/UX, modernen JavaScript-Frameworks und neuen Ansätzen wie Vibe Coding und AI Agents beschäftigten. Der klare fachliche Fokus, die Tiefe der Vorträge und der direkte Austausch auf Augenhöhe machten schnell klar: Die Konferenz richtet sich nicht an Neugierige, sondern an echte Praktiker:innen. Die Organisation war top und das Catering im KOMED hervorragend – ideale Voraussetzungen für konzentriertes Networking und Lernen.

Doch was die c’t webdev wirklich auszeichnet, war die spezifische Zielgruppe: Es handelte sich um eine klare Frontend-Konferenz. Das Publikum war tief in den Themen UI/UX, Coding mit AI Agents, Vibe Coding und den aktuellen JavaScript-Frameworks (React, Angular, Vue) verwurzelt. Hier traf man auf gleichgesinnte Frauen und Männer, die nicht nur auf der Suche nach Inspiration waren, sondern auch den tiefen fachlichen Austausch suchten. Der Vibe stimmte sofort, was eine ideale Basis für die kommenden Vorträge legte.

Tag 1: Über AI Autopilots, Architektur und granularem State-Management

Keynote: Von Copilot zu Autopilot

Der Tag begann mit einer fesselnden Keynote von Daniel Sogl, der uns mitnahm auf die Reise „From Copilot to Autopilot – How AI Coding Tools Are Transforming the Developer Role“. Der Vortrag war mehr als eine Bestandsaufnahme; er war eine Aufforderung, die neue Realität kritisch zu hinterfragen.

Sogl präsentierte eindrucksvolle Statistiken zur Adoption von AI-Tools, wobei 84 % der Entwickler sie bereits nutzen oder planen zu nutzen, und 51 % sie täglich verwenden. Diese Tools versprechen echte Produktivitätssteigerungen, wie z. B. eine um 55,8 % schnellere Aufgabenerledigung in kontrollierten Studien und eine Reduzierung der täglichen Arbeitszeit um 56 Minuten.

Der zentrale Weckruf kam mit dem Trust Paradox: Während Syntax-Fehler dank AI um bis zu 76 % reduziert werden, steigt das Risiko für tiefer liegende, architektonische Probleme signifikant an. Berechtigungsprobleme (+322 %) und Architekturmängel (+153 %) sind laut Sogl keine Seltenheit. Diese Zahlen haben mich am meisten überrascht und bestätigen meine Skepsis: AI erzeugt „saubereren“ Code, verleitet aber zur Vernachlässigung der architektonischen Kontrolle.

Die Quintessenz des Vortrags: Die Entwicklerrolle wandelt sich vom reinen Coder zum Orchestrator und Strategen. Die Zukunft liegt in der Spec-Driven Development (SDD), bei der wir die Spezifikationen klar vorgeben, bevor die AI den Code generiert. Genau hier liegt für mich eine der großen Herausforderungen der nächsten Jahre: Wir müssen uns stärker als je zuvor auf die architektonische Planung und saubere Anforderungsanalyse konzentrieren, um die AI als präzises Werkzeug zu führen, statt uns von ihren zufälligen ‚Vibes‘ treiben zu lassen.

​

Das Highlight von Tag 1: Signals in Depth

Nach der strategischen Keynote, die den Rahmen für die Zukunft der Entwicklerrolle setzte, tauchten wir am späten Vormittag tief in die Frontend-Architektur ein. Mein persönliches Highlight von Tag 1 war ein Vortrag, der zeigte, wie die modernen Frameworks das Kernproblem der Webentwicklung – die Reaktivität – endlich effizient lösen: „Signals in Depth – How reactivity works in many frontend frameworks“ von Garrelt Mock.

Mock erklärte anschaulich die Schwächen traditioneller Reaktivitätsansätze: das „Dirty Checking“ (bekannt aus älteren Angular-Versionen mittels Zone.js) und das Virtual DOM (VDOM) Diffing in React. Diese Methoden, obwohl funktional, verursachen oft Performance-Overhead und unnötige Rechenzyklen, da unnötig große Teile der Komponenten neu gerendert werden, selbst wenn sich nur ein kleiner Datenpunkt geändert hat.

Die Lösung liegt in Signals, die auf einem granularen Observer-Pattern basieren: Ein Signal weiß genau, welche UI-Teile oder Effekte von ihm abhängen. Bei einer Änderung wird nur dieser spezifische abhängige Effect aktualisiert, nicht die gesamte Komponente.

Für mich war dieser Vortrag die wichtigste technische Erkenntnis des Tages. Die Eleganz und Effizienz, mit der Signals die Notwendigkeit für komplexe Mechanismen wie Zone.js oder VDOM-Diffing eliminieren und Frameworks wie SolidJS, Preact und das neue Angular schneller und speichereffizienter machen, ist ein klarer Hinweis auf einen Paradigmenwechsel im State-Management. Die Frontend-Architektur wird sich dadurch grundlegend vereinfachen – ein Muss für jede skalierbare Anwendung in den kommenden Jahren.

Der Rest des ersten Tages: Von AI-Agents bis zur Frontend-Architektur

Neben Keynote und Signal-Tiefgang bot der erste Konferenztag eine spannende Bandbreite an Themen, die die aktuellen Herausforderungen und Trends in der Frontend-Welt widerspiegelten.

AI-Driven Development: Sebastian Springer beleuchtete in seiner Session „AI Agents Beyond Simple Chatbots“ die Entwicklung komplexer, autonomer AI-Lösungen und proaktiver Assistentensysteme, die weit über einfache LLM-Chat-Interfaces hinausgehen. Er zeigte Frameworks wie LangChain, mit denen man AI-Agents befähigen kann, reale Probleme zu lösen und mehrstufige Workflows zu automatisieren.

Architektur und Skalierung: Der Vercel-Partner-Talk „From Monolith to Microfrontends: Choosing the Right Architecture…“ von Yi Min Yang lieferte einen praktischen Leitfaden zu modernen Frontend-Architektur-Patterns. Er diskutierte alles von Monorepos (z.B. mit Turborepo) bis Microfrontends und präsentierte ein klares Entscheidungs-Framework, um die passende Architektur für Teamgröße und technische Anforderungen zu finden. Sehr interessant zu sehen, wie man auch step-by-step Architekturen modernisieren kann.

Qualität und Metriken: Richard Gross erklärte unter dem Titel „Making sense of frontend code with forensic techniques“, wie man mithilfe von Tools wie CodeCharta und CodeGraph die Code-Qualität und Architektur in Projekten mit hunderttausenden Zeilen analysiert. Darüber hinaus zeigte Eva Feigl in „Beyond clicks: Measuring UX, outcomes and real product success“ auf, wie man Produkt-Telemetrie und qualitative Nutzerforschung kombiniert, um wirklich verwertbare UX-Metriken zu erhalten und den Produkterfolg zu validieren.

Tag 2: Menschliche Empathie und AI-Strenge 

Keynote: Nobody needs UX – Die Unverzichtbarkeit der Empathie

Der zweite Konferenztag begann mit einer provokanten und nachdenklich stimmenden Keynote von Vicky Pirker mit dem Titel „Nobody needs UX“.

Pirker nutzte diesen vermeintlich paradoxen Titel, um die Essenz von User Experience (UX) in Zeiten der schnellen AI-Entwicklung neu zu definieren: Es braucht nicht den Begriff UX, sondern die menschliche Haltung dahinter. Schlechte UX führt zu Frustration und Ablehnung, wie sie eindrücklich zeigte.

Besonders relevant war die Diskussion im Kontext der AI-Revolution. Ihre klare Schlussfolgerung: User Experience bleibt menschzentriert, und KI dient lediglich als unser Sidekick. Die Aufgabe der Entwickler und Designer ist es, die Vision zu formen und die Nutzer zu begeistern.

Für mich war der Fokus auf die Empathie der wichtigste Takeaway. Während KI gut darin ist, bekannte UX-Schemata und Design-Regeln zu erlernen und perfekt umzusetzen, bleibt die Fähigkeit, sich tief in den User hineinzufühlen – also die Wünsche und emotionalen Reaktionen vorherzusehen – eine zutiefst menschliche Leistung. Dieser Mangel an Empathie kann aber zum Problem werden, wenn KI versucht, UX komplett zu übernehmen. Daher muss die menschliche Perspektive, die qualitative Nutzerforschung und Empathie stets die letzte Kontrollinstanz bleiben.

Das Highlight von Tag 2: EXACT Coding gegen den „Vibe“

Die Keynote von Vicky Pirker stellte klar: Der Mensch muss die ethische und empathische Kontrolle behalten. Der darauf folgende Vortrag „AI-Powered Development Vibe Code Doesn’t Work!“ von Marco Emrich und Ferdinand Ade lieferte die technische Methodik dazu. Sie äußerten eine klare Kritik am unstrukturierten „Vibe Coding“ (generieren, akzeptieren, nicht prüfen) und belegten, dass dieser Ansatz – obwohl schnell – zu unsauberen und unsicheren Codebasen führt.

Ich sehe Vibe Coding als einen effizienten Weg für schnelles Prototyping und Proof-of-Concepts; man erhält in kürzester Zeit gute, lauffähige Ergebnisse. Doch für Production-Ready Code ist dieser Ansatz meiner Meinung nach untauglich.

Die Lösung der Sprecher war EXACT Coding, ein Ansatz, der die besten Seiten der AI mit der Disziplin etablierter Methoden kombiniert. EXACT Coding basiert auf EXample-Guided Ai-CollaboraTive.

Das ist die Essenz für professionelle Softwareentwicklung: Bevor die AI überhaupt mit dem Codieren beginnt, müssen wir als Software Engineers in unseren Teams die Anforderungen und Spezifikationen klar erfassen und visualisieren. Der Mensch (Human-in-the-Loop) definiert das „Was“ durch die Beispiele und Tests; die AI übernimmt die Implementierung.

Der größte Vorteil dieser Methodik ist die Qualitätssicherung der Architektur: Indem wir uns zuerst auf Spezifikationen und die „Red“-Phase des TDD-Zyklus konzentrieren, zwingen wir die KI, in einem engen, validierten Rahmen zu arbeiten. Das beugt nicht nur Syntaxfehlern vor, sondern verhindert auch das Auseinanderdriften von Code und Gesamtarchitektur. Nur so stellen wir sicher, dass wir nicht nur Code schreiben, sondern nachhaltige, wartbare Software entwickeln und dabei niemals das große Ganze aus dem Auge verlieren.

Weitere Highlights an Tag 2: Reaktivität, Testing und Agenten-Interfaces

Auch abseits der Keynote und des AI-Vortrags lieferte Tag 2 wertvolle Inhalte, die sich tief mit den technischen Details der modernen Frontend-Entwicklung beschäftigten:

Standardisierung von AI-Interfaces: Max Marschall stellte in seinem Vortrag „AG-UI & MCP: Standardizing Agentic Web Interfaces“ zwei neue Protokolle vor: AG-UI (Agent-User Interaction Protocol) und MCP (Model Context Protocol). Diese zielen darauf ab, die Interaktion zwischen intelligenten Agents und modernen Web-Frontends zu standardisieren und modularer, testbarer und verständlicher zu gestalten.

Test-Qualität: Marco Emrich leitete die interaktive Session „How valuable are your tests?“. Er präsentierte die „Four Pillars of a Good Test“ von Vladimir Khorikov, um Kriterien für eine objektive Bewertung des Nutzens von Tests zu schaffen und so eine fundierte Diskussion über Teststrategien zu ermöglichen.

Accessibility in Komponenten: Und natürlich das beinahe-Highlight „Accessible Web Components“ von Anna Maier. Sie lieferte einen wichtigen Einblick, wie man technische Fallstricke des Shadow DOM vermeidet, um die Barrierefreiheit von Komponenten von Anfang an zu gewährleisten, und betonte die Notwendigkeit, dies auch im Produktkontext zu testen und zu dokumentieren.

Fazit: Eine lohnende Investition in die Frontend-Zukunft

Die zwei Tage auf der c’t webdev conference im Kölner MediaPark waren für mich eine absolut lohnende Investition. Die Konferenz lieferte nicht nur einen umfassenden Überblick über die aktuellen Tools und Frameworks (von Signals bis React Fullstack), sondern beleuchtete vor allem die strategischen und methodischen Herausforderungen der Branche. Der Fokus lag klar auf der Zukunft der Entwicklerrolle: Wir bewegen uns vom reinen Code-Schreiber hin zum Orchestrator, der AI strukturiert einsetzt und dabei die menschliche Urteilsfähigkeit (Human Judgement) behält.

Die wichtigste Erkenntnis: Der Mensch bleibt die Kontrollinstanz

Die entscheidenden Takeaways liegen für mich in der methodischen Disziplin und Empathie. Wir haben gelernt, dass wir AI nicht blind vertrauen dürfen (Stichwort: Trust Paradox bei Architekturmängeln), sondern dass unser menschliches Urteilsvermögen und die Fähigkeit zur Empathie die unverzichtbaren Kontrollinstanzen bleiben.

Networking und Empfehlung

Abgesehen vom Inhalt war die Atmosphäre auf der Konferenz herausragend. Die Teilnehmer:innen waren sehr freundlich und offen für einen fachlichen Austausch, was das Networking sehr erleichtert hat.

Ich kann die c’t webdev conference definitiv uneingeschränkt weiterempfehlen, da sie wertvolle Beiträge und tiefgreifende Infos aus der Tech-Branche im Bereich Frontend liefert. Die Konferenz richtet sich an diejenigen, die wissen wollen, wie man die Zukunft baut, nicht nur, wie man sie benutzt. Ob ich im nächsten Jahr wieder dabei bin, steht noch offen – schließlich soll man als Entwickler auch mal über den Tellerrand hinausschauen. Aber die Impulse aus Köln sind gesetzt und werden meine Arbeit nachhaltig prägen.

Timo Kaiser

Senior Software Engineer

Timo ist ein erfahrener Webentwickler mit über 15 Jahren Projekterfahrung, insbesondere in der Umsetzung moderner, barrierefreier Frontends auf Basis von Angular, TypeScript, HTML und SCSS. Sein Schwerpunkt liegt auf der Entwicklung skalierbarer, wartbarer und zugänglicher Webanwendungen.

Als Lead Developer verantwortet er in Projekten die technische Umsetzung, Architekturentscheidungen sowie die kontinuierliche Optimierung der User Experience. Timo ist Ansprechpartner für technische und methodische Fragen, übersetzt Anforderungen in strukturierte Sprints und Git-Workflows und sorgt durch Code-Reviews, Pairing und Coaching für hohe Qualität und Effizienz im Team. Er arbeitet eng mit Design- und UX-Teams zusammen und bringt seine gestalterische Erfahrung auch in Tools wie Figma oder Adobe XD ein.

t.kaiser@atra.consulting    

• LinkedIn

Als technologieagnostische Konferenz bietet das SAG weniger Deep Dives, dafür aber einen breit gefächerten und gut zugänglichen Überblick über den aktuellen „Architektur-Mainstream“ in Deutschland. Man trifft viele bekannte Gesichter und das Programm ist üblicherweise mit namhaften nationalen wie internationalen Sprecherinnen und Sprechern besetzt. In diesem Jahr etwa mit Bernd Ruecker (Co-Founder Camunda, mit – Überraschung – einem halben, aber sehr sympathischen Werbevortrag), Cheryl Hung (ehem. CNCF), Alistair Cockburn (Mitautor des Agilen Manifests) oder Gregor Hohpe (dessen launisch-meinungsstarke Vorträge ich seit jeher mag).

Der Nachteil dieser breiten und bewusst agnostischen Ausrichtung liegt allerdings auf der Hand: Viele Themen bleiben eher an der Oberfläche. Auch in diesem Jahr gab es ausschließlich Talks der Kategorien „Beginner“ und „Intermediate“ – wirklich neue Erkenntnisse sind dementsprechend selten.

Wir waren dennoch vor Ort – und möchten im Folgenden ein paar Eindrücke teilen.

Themenlandschaft: weniger AI-Dominanz als erwartet

Ein Blick auf die Agenda brachte die erste Überraschung. Trotz ordentlicher Präsenz war AI nicht erdrückend dominant – für eine Architekturkonferenz zur aktuellen Zeit fast wohltuend. „Nur“ ungefähr jeder sechste Talk drehte sich explizit um die Themen AI, wobei natürlich sehr viele Sessions das Thema zumindest gestreift haben. Im Sprachgebrauch des Gartner Hype Cycle sind wir nun wohl endgültig über den Peak of Inflated Expectations hinaus und arbeiten uns langsam, aber sicher, hin zu wirklichen und nachhaltigen Use Cases.

Statt GenAI waren sozio-technologische Fragestellungen oder auch der Dauerbrenner DDD in diesem Jahr wieder deutlich präsenter.

Auch Green IT, ein Thema, von dem ich mir vor drei bis vier Jahren eine dauerhafte Etablierung erhofft hatte und das spätestens vom energieverschlingenden GenAI-Hype ein wenig in den Hintergrund gedrängt worden ist, war (für mich) überraschend präsent. Letzteres mag damit zu tun haben, dass das iSAQB seit vergangenen Jahr ein neues Modul „Green IT“ in seiner Advanced-Zertifizierung anbietet [1].

Vibe Coding, Verantwortung und Plattformarchitektur

Unter den Vorträgen ist mir der Talk „Vibe Coding Auth Without Melting Down!“ von Cheryl Hung besonders in Erinnerung geblieben [2]. Er ging der Frage nach, ob sich auch fehlerintolerante Bereiche wie Authentifizierung mittels Vibe Coding lösen lassen. Die Antwort: It depends. In ihrem Beispiel zeigte sie eine mit Claude Code generierte Authentifizierungslösung, die funktional war, aber typische handwerkliche Anfängerfehler enthielt – etwa die Verwendung veralteter Hash-Bibliotheken oder das unbeabsichtigte Leaken von Nutzerinformationen [3]. Das deckt sich sehr mit meinen eigenen Erfahrungen: Vibe Coding liefert einen erstaunlich brauchbaren, aber eben nicht fehlerfreien Ausgangspunkt [4].

Spannend war allerdings weniger der Code selbst, sondern Cheryls Vorgehen: Sie hat die Sicherheitslücken nicht eigenhändig gesucht, sondern Claude Code im einmal generierten Code gezielt nach Schwachstellen analysieren lassen – eine Vorgehensweise, die in der Praxis zunehmend eingesetzt wird [5]. Einerseits nicht unerwartet, andererseits irgendwie faszinierend – das LLM „weiß“ grundsätzlich von diesen Schwachstellen, muss aber erst in die richtige Richtung geleitet werden.

Damit bleibt Vibe Coding für mich auf einem Niveau, das signifikante Geschwindigkeitsvorteile ermöglicht – solange man den Leitsatz beachtet: Never vibe code an app you wouldn’t be able to code yourself. Ob das im Startup-Kontext immer beherzigt wird? We will see…

Als möglichen Lösungsansatz griff Cheryl das Konzept Shift Down Security auf. Während Shift Left als etabliertes Prinzip die frühzeitige Verlagerung von Verantwortung – etwa für Qualität, Tests, Sicherheit oder Architektur – in die Entwicklungsteams und in die frühe Phase des Entwicklungsprozesses beschreibt, setzt Shift Down an einer anderen Stelle an: Statt Verantwortung weiter nach vorne zu schieben, wird sie bewusst nach unten, also auf Plattform- und Infrastruktur-Level, verlagert [6][7].

Dort werden Sicherheitsmechanismen technisch und organisatorisch verankert – etwa durch vordefinierte, abgesicherte Base Images, verpflichtende Policies, vorstrukturierte Toolchains oder Plattform-Guardrails, die bestimmte Fehler (menschliche wie maschinelle) gar nicht erst zulassen. Dieser Gedanke deckt sich stark mit dem Prinzip sogenannter Enabling Constraints: Bedingungen, die nicht einschränken, sondern Qualität und Sicherheit gezielt ermöglichen [8].

Ein Konzept, das sowohl menschlichen als auch KI-basierten Entwicklerwerkzeugen hilft, typische Fehler gar nicht erst entstehen zu lassen. Und noch dazu ein netter Querverweis zum Talk von Michael Mahlberg war, in welchem Enabling Constraints eine wichtige Rolle einnehmen [9].

Der Übergang von Vibe Coding zu Shift Down war für meinen Geschmack etwas abrupt, zumal die gezeigten Authentifizierungsfehler kaum über Plattformmechanismen lösbar gewesen wären. Trotzdem ein sehr gelungener Talk mit einem prägnanten Beispiel sowie einem für mich neuen und interessanten Konzept.

Hexagons, Ports & Adapter

Auch der Vortrag von Alistair Cockburn zur hexagonalen Architektur [10] – laut ihm selbst eine der drei schlimmsten Benennungen von Architekturkonzepten überhaupt – war eine der Sessions, die gleichzeitig unterhaltsam, temporeich und technisch fundiert waren. Zum einen ist es schlicht faszinierend, den Urheber eines Architekturstils über Historie, Motivation und ursprüngliches Designziel sprechen zu hören. Zum anderen hat Alistair den Vortrag sehr geschickt mit konkreten Implementationsbeispielen aus unterschiedlichen Sprachen kombiniert.

Allein das Tempo machte den Talk für mich zum anspruchsvollsten Vortrag, den ich die Tage gehört habe – und damit zur willkommenen Abwechslung zu den insgesamt sehr gut gemachten, aber oft sehr einsteigerorientierten Sessions. Ein einzelnes fachliches Learning würde ich rückblickend gar nicht herausgreifen. Stattdessen hat sich mein Eindruck bestätigt, dass Port-&-Adapter-Architekturen zu den Stilformen gehören, mit denen sich jede Entwicklerin und jeder Architekt ernsthaft beschäftigt haben sollte (und spätestens dann versteht, wie ich von Hexagons zu Ports & Adaptern komme).

Fazit: Vor allem eine gute Orientierung

Was bleibt für mich am Ende vom SAG? Am Ende war es inhaltlich zumeist nicht revolutionär, aber durchaus wertvoll. AI war präsent, DDD sowieso – und manche Konzepte wirken erstaunlich robust gegenüber Hype-Zyklen. Vielleicht ist genau das der eigentliche Reiz des SAG: Man nimmt selten ein einzelnes atemberaubendes Konzept mit nach Hause, aber jedes Jahr ein etwas klareres Verständnis davon, warum sich bestimmte Ideen in der Architektur so hartnäckig halten. Und vielleicht reicht das völlig.

Referenzen

1. iSAQB Advanced Level Module – Green IT
   https://isaqb.org/certifications/advanced-level/green-it/ 
2. Keynote: Vibe Coding Auth Without Melting Down!
   https://conferences.isaqb.org/software-architecture-gathering/session/keynote-vibe-coding-auth-without-melting-down/ 
3. Cheryl Hung – Vibe Coding Auth Without Melting Down (Slides)
   https://www.slideshare.net/slideshow/cheryl-hung-vibe-coding-auth-without-melting-down-isaqb-software-architecture-gathering-2025-pdf/284317660 
4. Ein halber Tag im Leben eines Vibecoders
   https://atra.consulting/engineering/ein-halber-tag-im-leben-eines-vibecoders 
5. Passing the Security Vibe Check: The Dangers of Vibe Coding
   https://www.databricks.com/blog/passing-security-vibe-check-dangers-vibe-coding 
6. Shift-Down Security (SIG-Security Working Paper)
   https://raw.githubusercontent.com/kubernetes/sig-security/main/sig-security-docs/papers/shift-down/shift-down-security.md 
7. What is Shift-Down Security?
   https://nirmata.com/2024/09/13/what-is-shift-down-security/ 
8. The Magic Power of Enabling Constraints
   https://www.scrum.org/resources/blog/magic-power-enabling-constraints
9. Now We’ve Given Them Every Freedom – and They Still Don’t Do What We Want
   https://conferences.isaqb.org/software-architecture-gathering/session/now-weve-given-them-every-freedom-and-they-still-dont-do-what-we-want/ 
10. The Hexagonal or Ports & Adapters Architecture
    https://conferences.isaqb.org/software-architecture-gathering/session/the-hexagonal-or-ports-adapters-architecture/
    

Daniel Wochnik

Geschäftsbereichsleitung »Finanzdienstleistungen«

Daniel ist seit 2017 in der IT-Branche aktiv und bringt seine umfassende Erfahrung als Senior Managing Consultant und Geschäftsbereichsleiter für Finanzdienstleistungen bei atra.consulting ein. Besonders begeistert ihn das Zusammenspiel technischer, methodischer und organisatorischer Aspekte. Als leidenschaftlicher Läufer und bekennender 1. FC Köln-Fan hat er seine Leidensfähigkeit auch privat mehrfach unter Beweis gestellt. Seine Kunden unterstützt er als Softwarearchitekt, agiler Coach und Berater bei der nachhaltigen und zielgerichteten Umsetzung von Entwicklungsprojekten.

d.wochnik@atra.consulting    

• LinkedIn

Wie holen wir das Beste aus unseren Java-Anwendungen heraus? Zu diesem Thema gab Karsten Silz bei uns im Stuttgarter Office einen tiefen Einblick in die aktuellen Möglichkeiten der Performance-Optimierung.

Gerade in Zeiten von Serverless Computing und Microservices ist die Startzeit von Java-Anwendungen ein kritischer Faktor. Karsten zeigte uns anschaulich die Bandbreite der Möglichkeiten auf – vom einfachen Spring Boot Tuning über Class Data Sharing (CDS) und Project Leyden bis hin zu Project CRaC und GraalVM Native Image.

Besonders wertvoll war dabei der Blick auf die Wirtschaftlichkeit: Nicht jede technische Optimierung rechnet sich am Ende auch betriebswirtschaftlich.

Wer den Vortrag verpasst hat oder tiefer in die technischen Details, Benchmarks und ROI-Berechnungen einsteigen möchte, findet alle Informationen, Folien und Beispiel-Code direkt in Karstens Zusammenfassung.

Timo Kaiser

Senior Software Engineer

Timo ist ein erfahrener Webentwickler mit über 15 Jahren Projekterfahrung, insbesondere in der Umsetzung moderner, barrierefreier Frontends auf Basis von Angular, TypeScript, HTML und SCSS. Sein Schwerpunkt liegt auf der Entwicklung skalierbarer, wartbarer und zugänglicher Webanwendungen.

Als Lead Developer verantwortet er in Projekten die technische Umsetzung, Architekturentscheidungen sowie die kontinuierliche Optimierung der User Experience. Timo ist Ansprechpartner für technische und methodische Fragen, übersetzt Anforderungen in strukturierte Sprints und Git-Workflows und sorgt durch Code-Reviews, Pairing und Coaching für hohe Qualität und Effizienz im Team. Er arbeitet eng mit Design- und UX-Teams zusammen und bringt seine gestalterische Erfahrung auch in Tools wie Figma oder Adobe XD ein.

t.kaiser@atra.consulting    

• LinkedIn

Retrospektiven gelten als Herzstück agiler Teams – doch was, wenn sie sich nur noch wie ein weiteres Meeting anfühlen? In diesem Artikel schildere ich, wie ich selbst in die Falle der „Retro Fatigue“ getappt bin, welche Muster mir dabei aufgefallen sind und wie wir Retros wieder zu echten Räumen für Verbesserung machen können. 

Beruflich gesprochen bin ich mit agiler Softwareentwicklung groß geworden. Als ich 2017 meine ersten Schritte bei einer großen deutschen Traditionsversicherung machte, waren hippe Agile-Trainingscenter mit Kickertisch und Gratiskaffee sowie der Trend zu autonomen Teams mit mehr Freiheitsgraden selbst dort längst angekommen. Und was soll ich sagen? Vielleicht lag es auch an meiner ersten Führungskraft, die noch eher vom Typ „Excelliste & Rapport-Planung“ war – aber ich war sofort fasziniert von der agilen Denkweise, die motivierte Individuen und ein funktionierendes Produkt in den Mittelpunkt stellt. Vom ersten Tag an hätte ich mich wohl als Agilist bezeichnet – ohne den Begriff überhaupt zu kennen.

Auch heute noch begeistern mich Konzepte wie Modern Agile, und in meinen Projekten übernehme ich gelegentlich agile Rollen. Umso erstaunter war ich, als ich kürzlich feststellte: Ich freue mich nicht mehr auf meine Retrospektive. Im Gegenteil – der zweiwöchentliche Termin fühlte sich zunehmend wie eine lästige Pflichtaufgabe an. Wäre ich als Agile Master nicht qua Rolle der Hüter der Retro gewesen – ich hätte sie wohl abgesagt.

Dabei halte ich es eigentlich mit Woody Zuill, der sagte:

„If you adopt only one agile practice, let it be retrospectives. Everything else will follow.“

Wie konnte es soweit kommen? Wie wurde aus dem vielleicht wichtigsten Ritual der agilen Welt eine Routine, die ich (und vermutlich große Teile des Teams) als wenig wertvoll empfand?

Eins vorweg: Nicht jede Retro war schlecht. Es gab großartige Diskussionen und wertvolle Impulse für Verbesserungen. Und ja, vermutlich habe ich mich im operativen Tagesgeschäft manchmal zu sehr verfangen und Inspect & Adapt nicht immer priorisiert.

Aber dennoch … die Retros fühlten sich oft wie eine Pflichtübung an. Wie kam es zu dieser Retro Fatigue? Und was kann man dagegen tun?

Inspect ohne Adapt

Es beginnt oft leise: Ein Action Item verschwindet in der Jira-Tiefe. Ein anderes bleibt ohne Besitzer. Beim dritten ist unklar, was es eigentlich bedeuten soll. Niemand sagt es laut, aber alle spüren es – da bewegt sich wenig. Die Retro war nicht schlecht, aber auch nicht wirksam. Genau hier entsteht sie: die stille Enttäuschung, die sich Retro für Retro summiert. Und plötzlich fragt man sich: Warum machen wir das eigentlich noch?

Ich glaube, genau dieser Punkt ist der gefährlichste Kipppunkt jeder Retrokultur. Denn auch wenn das Gespräch gut war – wenn aus den Erkenntnissen keine Veränderung entsteht, schlägt Reflexion in Frustration um. Das Team spürt: Wir reden, aber es passiert nichts. Und mit jedem unerledigten Action Item sinkt die Bereitschaft, sich beim nächsten Mal einzubringen.

Die Ursachen dafür sind vielseitig – und meist ganz banal. Maßnahmen werden vage formuliert („Wir sollten mehr aufeinander achten“), bleiben ohne Verantwortliche oder versickern einfach im Alltag. Besonders tückisch: Oft merkt es niemand sofort. Doch wenn es zur Gewohnheit wird, dass auf Retros keine Veränderung folgt, wird aus dem wichtigsten agilen Ritual ein frustrierendes Meeting mit Alibi-Charakter.

Was hilft? Klare, konkrete Maßnahmen – versehen mit Zuständigkeit, Frist und Sichtbarkeit. Und: Mut zur Ehrlichkeit. Wenn ein Thema dem Team nicht wichtig genug ist, um Energie hineinzustecken, dann darf es auch bewusst verworfen werden. Alles andere ist Selbsttäuschung. Und ja, auch als Scrum Master oder Agile Coach sollte man sich nicht reflexartig jedes „verwaiste“ To-do greifen. Denn wenn sich niemand verantwortlich fühlt, ist das oft die deutlichere Botschaft als jede Diskussion.

Nicht zuletzt hilft es, Erfolge auch sichtbar zu machen – und sei es nur ein kleiner Schritt. Denn nichts motiviert mehr als das Gefühl: Wir können etwas verändern.

Zu große oder zu heterogene Teams

Wer kennt es nicht? Während beispielsweise der Scrum Guide 3 bis maximal 9 Teammitglieder für ein agiles Team empfiehlt, finden sich in der Realität oft riesige Teams von 10, 15 oder gar über 20 Teammitgliedern. Dies führt nicht nur unweigerlich zu „Teams in Teams“, sondern sorgt auch dafür, dass die Retro sich anfühlt wie ein Meeting-Marathon ohne Fokus. Oft sprechen nur wenige, während sich andere zurücklehnen oder gedanklich ausklinken. Einzelne Stimmen gehen unter oder wiederholen sich. Entscheidungen werden verwässert, Diskussionen enden in Allgemeinplätzen.

In solchen Situationen hilft es, bewusst kleinere Gruppen zu bilden, etwa durch eine Retrospektive in Subteams mit anschließendem Austausch der Erkenntnisse. Auch das Wechseln der Perspektive – etwa durch gezielte Fragestellungen pro Teambereich – kann helfen, mehr Relevanz und Beteiligung zu erzeugen. 

Am Ende lässt sich dieses Problem jedoch nur bedingt im Team lösen: Wenn das Team zu groß ist, um gemeinsam wirklich reflektieren zu können, dann ist das kein Zeichen gegen die Retro – sondern ein klarer Hinweis auf ein organisatorisches Problem. 

Retro overload

Während so gut wie alle agilen Events, von Sprintplannung über Daily Standups bis zu Reviews, mehr oder weniger regelmäßig hinterfragt oder zumindest kritisiert werden, scheinen Retrospektiven in den meisten Teams heilig. Und das ist doch gut so, oder?

Immerhin ist Inspect & Adapt der zentrale Gedanke agilen Arbeitens und ich selbst habe Woody Zuills Aussage zur Wichtigkeit von Retrospektiven zu Beginn dieses Artikels zitiert.

Ganz so einfach ist es in meinen Augen dann aber doch nicht. Vermutlich haben die meisten bereits Retros erlebt, an dem die Leute verschlossen, abgelenkt, unmotiviert oder einfach genervt von Gott und der Welt waren. Natürlich kann man hier durch gute Vorbereitung und Moderation sowie einem gemeinsamen Verständnis der Wichtigkeit einer Retrospektive viel erreichen. Aber dennoch glaube ich, manche Retros sind von vornherein zum Scheitern verurteilt.

Vielleicht sind die Teams noch nicht so weit, im vorgesehenen Rhythmus gemeinsam zu reflektieren. Vielleicht fehlt Vertrauen oder sind Verhaltensweisen oder Organisationen so festgefahren, dass Veränderung einfach eine gewisse Zeit brauchen. Es gibt viele Gründe, weswegen Teams zu viele Retros durchführen können. Dabei führen viele Retros eben nicht zu besonders viel Inspect & Adapt, sondern zu kompletten Stillstand. Frei nach Paracelsus: Die Dosis macht das Gift.

Gerade weil Retros so wichtig sind, trauen sich meiner Erfahrung nach die wenigsten Teams oder Coaches wirklich, ihre Retros kritisch zu hinterfragen. Dabei ist genau diese Reflektion zentral, um Meetings wirklich wertvoll zu machen. Und ich lade jedes Team herzlich ein, in der nächsten Retro einmal über den Sinn – und Unsinn der eigenen Retro zu diskutieren.

Fokus auf den Circle of Concern

Eine Kunst bei Retrospektiven ist es, den Blick über den Tellerrand zu werfen und gleichzeitig vor allem das eigene Verhalten zu reflektieren.

Allzu häufig beobachten wir jedoch eine Fixierung auf den „Circle of Concern“ – also Themen, die zwar die Arbeit des Teams beeinflussen, auf die es aber keinen direkten Einfluss hat. Da wird dann über Tools, die Unternehmensleitung, unklare Strategie oder die Organisation als Ganzes geschimpft. Und ja, manches davon ist durchaus berechtigt – aber selten produktiv.

In Retros geht es vor allem um Selbstwirksamkeit. Um den „Circle of Influence“. Also um die Frage: Was können wir ändern? Wo liegt unser Gestaltungsspielraum? Sich das immer wieder bewusst zu machen und notfalls auch mal freundlich, aber bestimmt zurück auf den Einflussbereich zu lenken, ist eine der wichtigsten Aufgaben eines guten Facilitators.

Manchmal hilft hier ein Perspektivwechsel: Etwa durch gezielte Fragen wie „Was war unser Anteil daran?“ oder „Was würden wir anders machen, wenn wir es allein entscheiden könnten?“ – und manchmal wandelt sich tatsächlich ein Ohnmachtsgefühl in einen konkreten Handlungsspielraum.

Infantilisierung von Mitarbeitern und Monotonie

Viele Retros laufen nach einem sehr ähnlichen Muster ab. Zuerst gibt es einen Checkin, um ein gutes Gesprächsklima zu schaffen. Danach werden Eindrücke und Themen aus der vergangenen Iteration gesammelt. Hieraus werden (oftmals priorisiert durch Dot-Voting) Erkenntnisse gemeinsam diskutiert und abgeleitet, bevor sich das Team auf Action Items einigt und die Retro mittels eines Check-Outs abschließt. Auch wenn es hier von Lego-, über Dino- und Superhelden-Retros verschiedenste Flavour gibt und sich die Details sicherlich unterscheiden (und die Unterscheidung sehr sinnvoll sein kann!) fallen doch die meisten Retros in dieses Schema. Und ermüden die Teams. Eigentlich tolle Hilfsmittel, wie der Retromat verstärken ein solches Muster nochmals. 

Natürlich wirkt sich dieser Faktor umso stärker aus, je weniger nachhaltige Ergebnisse die Retros wirklich produzieren (s.o.).

Auch wenn es etwas harsch klingt: Ich habe oftmals das Gefühl, auch im agilen Kontext neigen wir dazu, Kolleginnen und Kollegen zu infantilisieren. Dies beginnt damit, dass Widerstände gegen Change gerne mal mit “fehlendem agilen Mindset” weggewischt werden oder dass wir glauben, dass sich ein Teammitglied schon öffnet, wenn wir ihm schon genügend, auflockernde und teambildende Checkins und Möglichkeiten bieten. Dabei ist es eigentlich eine Grundannahme des agilen, Menschen wie Erwachsene zu behandeln.

Und genau dies ist meiner Erfahrung nach auch der richtige Weg: Das Team dort abholen, wo es startet und etwaige Störgefühle offen ansprechen. Zur Abwechslung auch mal gar keine oder nur eine minimale Struktur für die Retro vorzugeben und in einem offenen Format dem Team den Raum geben, Themen und Optimierungsmöglichkeiten zu besprechen, kann helfen, aus dem Trott auszubrechen. Auch abwechslungsreiche Formate wie ein Pre-Mortem sind in diesem Kontext spannende Werkzeuge.

Misstrauen (in das Management) 

Ich denke manchmal an Asterix & Obelix, wenn ich manche Teams in ihren Retros beobachte. Da sitzt ein gallisches Dorf zusammen, kämpferisch, eng verbunden, voller Stolz auf die eigene Selbstorganisation. Und draußen lauert das Imperium: das Management, die Enterprise Architekten, die fremdbestimmten Roadmaps. Was als gesunder Schutzmechanismus beginnt, kann schnell zur systemischen Trennung werden.

Besonders in Retros wird dieses Muster sichtbar. Immer wieder kommen dieselben Themen auf: fehlende Entscheidungsspielräume, widersprüchliche Impulse von außen, Tooling, das bremst. Doch je häufiger solche Punkte ohne spürbare Reaktion bleiben, desto mehr verfestigt sich im Team ein Gefühl von: „Die da draußen machen ja doch, was sie wollen.“ Und damit auch: „Dann machen wir hier halt unser Ding.“ Die Retro wird zur Bühne der Selbstvergewisserung – aber nicht mehr zur Brücke nach außen.

Agile Coaches tragen zu dieser Dynamik manchmal ungewollt bei. Indem sie Teams in ihrer Eigenständigkeit stärken, aber gleichzeitig versuchen, sie vor destruktiven oder unklaren Einflüssen von außen zu schützen. Das ist verständlich – aber auch gefährlich. Denn wenn das Team sich nur noch im Inner Circle bewegt, wird Selbstorganisation schnell zu Selbstabschottung. Die Retrospektive verkommt zur Selbstbespiegelung: Immer die gleichen Themen, immer die gleichen Perspektiven, keine echte Weiterentwicklung.

Was hilft? Brücken bauen. Zum Beispiel durch „Retro Reviews“ mit Stakeholdern, durch Eskalationsschleifen mit Feedback-Rückkanal oder durch die bewusste Einbindung von Führungskräften – nicht als Kontrolle, sondern als Dialogpartner. Besonders wichtig ist in diesem Kontext die Rolle des Product Owners – und anderer Personen, die sich in übergreifenden Gremien und Abstimmungen bewegen, auf einer Ebene, die viele als Flight Level 2 bezeichnen würden. Gerade wenn diese Rollen über lange Zeit eng im Team verankert waren, neigen sie dazu, Konflikte zu vermeiden und übernehmen häufig unbewusst die Narrative des Teams als „Good Buddy“. Wenn es ihnen jedoch gelingt, sich aus dieser Sichtweise zu lösen und gezielt Impulse von außen ins Team zu tragen, kann das die Retro wieder öffnen – für neue Perspektiven und echte Veränderung.

Denn ein gallisches Dorf ist stark – aber es muss anschlussfähig bleiben, wenn es nicht irgendwann alleine dastehen will.

Ein kleines Fazit 

Retrospektiven sind ein zentrales Werkzeug agiler Zusammenarbeit – und gleichzeitig anfällig für Abnutzung, Frustration und schleichende Bedeutungslosigkeit. Die in diesem Artikel beschriebenen Symptome von „Retro Fatigue“ habe ich nicht nur beobachtet, sondern teilweise selbst verursacht. Doch genau darin liegt auch eine Chance: Wenn wir den Mut haben, offen über unsere eigenen Routinen zu sprechen, können wir Retrospektiven wieder zu dem machen, was sie sein sollen – Räume für echte Reflexion, lernende Teams und kontinuierliche Verbesserung.

Also was würde ich zukünftig denn nun anders machen? Als allererstes wohl offen mit dem Team sprechen. Und einmal reflektieren, welche Anti-Pattern gerade eigentlich auf uns zutreffen.

Daniel Wochnik

Geschäftsbereichsleitung »Finanzdienstleistungen«

Daniel ist seit 2017 in der IT-Branche aktiv und bringt seine umfassende Erfahrung als Senior Managing Consultant und Geschäftsbereichsleiter für Finanzdienstleistungen bei atra.consulting ein. Besonders begeistert ihn das Zusammenspiel technischer, methodischer und organisatorischer Aspekte. Als leidenschaftlicher Läufer und bekennender 1. FC Köln-Fan hat er seine Leidensfähigkeit auch privat mehrfach unter Beweis gestellt. Seine Kunden unterstützt er als Softwarearchitekt, agiler Coach und Berater bei der nachhaltigen und zielgerichteten Umsetzung von Entwicklungsprojekten.

d.wochnik@atra.consulting    

• LinkedIn