Vergangene Woche waren mein Kollege Rendani und ich im Berliner nhow Hotel, zusammen mit rund 250 bis 300 anderen Menschen, die unsere Leidenschaft für Domain-Driven Design (DDD), Event Sourcing und durchdachte Softwarearchitektur teilen. Auf der KanDDDinsky 2025 war unsere erste Teilnahme an dieser Konferenz – nicht nur als Besucher, sondern als Sponsoren und Aussteller für die von uns entwickelte Datenbank EventSourcingDB.

Ein anderes Konferenzformat

Was uns sofort ins Auge fiel, war die Herangehensweise an die Zeitplanung. Statt des typischen Konferenzformats mit einheitlichen Session-Längen schufen die Organisatoren eine Puzzle-artige Agenda, die 50-minütige Vorträge mit 120-minütigen Hands-on-Workshops kombinierte. Die Sessions liefen in vier parallelen Tracks.

Dieses Format eröffnet interessante Wahlmöglichkeiten für die Teilnehmerinnen und Teilnehmer. Theoretisch ließ sich zwar zwischen Sessions wechseln, praktisch sah die Sache jedoch anders aus. Einen zweistündigen Workshop auf halbem Weg zu verlassen, um einen Vortrag mitzunehmen, ergibt nur bedingt Sinn – auch wenn wir beobachteten, dass einige Teilnehmer sich leise zur Halbzeit aus Vorträgen verabschiedeten, um eine andere Session zu besuchen. Eine elegante Lösung, die sowohl tiefgehende Einblicke als auch schnellen Wissensaustausch ermöglicht – etwas, das uns in dieser Form auf anderen Konferenzen bisher nicht begegnet ist.

Ebenso durchdacht war die viertägige Struktur: Workshops am Dienstag (21. Oktober), die Hauptkonferenz am Mittwoch und Donnerstag (22.-23. Oktober) und ein Open Space am Freitag (24. Oktober). Diese Progression von fokussiertem Lernen über breite Exploration bis hin zu Community-getriebener Konversation zeigt, wie sorgfältig die Organisatoren darüber nachgedacht haben, wie Menschen tatsächlich mit Konferenzen interagieren möchten.

Die Content-Landschaft

Die Bandbreite der Themen auf der zweitägigen Agenda war beeindruckend. Der Mittwoch startete mit einer interaktiven Keynote zur Modellierung in Software- und menschlichen Systemen, während der Donnerstag Vorträge von Ian Coopers „The Emissary“ bis hin zu Eric Evans höchstpersönlich über „AI and Tackling Complexity“ bot. Die Klassiker waren natürlich vertreten – CQRS, Event Sourcing, DDD-Pattern – standen aber gleichberechtigt neben Sessions zu Wardley Mapping, kollaborativer Modellierung, hexagonaler Architektur und Organisationsdesign.

Über beide Tage hinweg kristallisierten sich mehrere Themen heraus. Vor allem die Schnittstelle von KI und DDD ließ sich kaum ignorieren: Rinat Abdullins „When DDD Met AI: Practical Stories from Enterprise Trenches“, Eric Evans über die Bewältigung von Komplexität mit KI und Hila Fox‘ Diskussion sozio-technischer Systeme im KI-Zeitalter – alle deuteten auf eine Community hin, die sich aktiv damit auseinandersetzt, wie diese Welten aufeinanderprallen. Der Hands-on-Workshop „Epic Systems Design: Surviving Complexity“ von Jacqui und Steven Read fand am Donnerstag statt, ebenso wie eine reflektierende Session unter dem Titel „Over 20 Years of DDD – What We Know, What We Do, What Needs to Change“, quasi eine Meta-Konversation über die Praxis selbst.

Besonders interessant fanden wir, wie natürlich dabei KI ihren Weg in den Diskurs fand. Sessions wie Marco Heimeshoffs „Hybrid Intelligence“ und die verschiedenen KI-fokussierten Vorträge wurden nicht als Neuheiten behandelt, sondern als natürliche Erweiterungen der Kernthemen der Community. Das passt perfekt zu unserer Arbeit an eventsourcing.ai, wo wir thematisieren, wie KI und Event-getriebene Architekturen einander sinnvoll ergänzen können. Die Vorteile Event-getriebener Architekturen für KI-Anwendungen – Nachvollziehbarkeit, Time-Travel-Debugging, deterministische Replays – werden anscheinend zunehmend offensichtlich.

Die Closing Keynote am Donnerstag von Alberto Brandolini über „DDD Lessons from ProductLand“ rundete die Hauptkonferenztage ab: Eine der Koryphäen der Community reflektierte darüber, wie sich DDD-Erkenntnisse jenseits der reinen Softwareentwicklung anwenden lassen.

Die Konferenz fand vollständig auf Englisch statt, was ihren international geprägten Charakter widerspiegelt. Die Teilnehmer kamen hauptsächlich aus Europa – Deutschland, Österreich, Italien und darüber hinaus – und bildeten eine diverse, aber kohärente Community. Dass Inklusion den Organisatoren wichtig ist, zeigte sich sowohl im Speaker-Lineup als auch in der Art, wie die Veranstaltung strukturiert war.

Die größere Erkenntnis

Vielleicht war unsere wichtigste Einsicht aus diesen Tagen gar nicht technischer Natur – es ging um die Community selbst. Manchmal hört man die Einschätzung, DDD, CQRS und Event Sourcing seien Nischeninteressen, die von einer kleinen Gruppe Enthusiasten in isolierten Ecken praktiziert würden.

Die KanDDDinsky widerlegte diese Wahrnehmung eindrücklich. Ja, diese Ansätze sind nicht das, was alle machen. Sie sind nicht der Standard, der mit jedem Framework ausgeliefert oder in jedem Bootcamp gelehrt wird. Aber sie sind auch keineswegs exotisch. Wenn man sich in diesem pink getönten Konferenzraum umsah und Hunderte von Menschen aus zahllosen Unternehmen und Ländern beobachtete, wurde die Realität offensichtlich: Dies ist eine substanzielle, wachsende Community mit handfester Erfahrung im Bau von Produktivsystemen.

Die Gespräche, die wir führten, waren dabei alles andere als theoretisch: Menschen lösen konkrete Probleme mit diesen Pattern. Sie ringen mit echten Trade-offs, teilen ihre Erfahrungen aus dem Alltag und lernen aus den Erfolgen und Misserfolgen der anderen. Dies ist ein ausgereifter Praxisbereich, keine experimentelle Spielwiese.

Für uns hat diese Bestätigung Gewicht. Wir bauen EventSourcingDB, weil wir überzeugt sind, dass Event Sourcing und CQRS erstklassige Tooling-Unterstützung verdienen. Die Größe und das Engagement dieser Community zu erleben, bestätigt uns darin, dass echte Nachfrage nach Tools besteht, die diese Pattern zugänglicher machen.

Ausblick

Die beiden Konferenztage setzten einen starken Akzent, wobei der Open Space am Freitag noch bevorstand, um die Gespräche in einem offeneren Format fortzuführen. Die Mischung aus Vorträgen und Workshops schuf natürliche Rhythmen – intensive Lernsessions, gefolgt von Networking und Zeit zum Verdauen. Die Location funktionierte einwandfrei, die Organisation lief reibungslos, und die Community war einladend.

Wir verarbeiten noch immer all das, was wir gelernt haben, und all die Menschen, die wir kennengelernt haben. Das ist das Zeichen einer guten Konferenz – wenn man mit mehr Fragen als Antworten nach Hause fährt und mehr Kontakte geknüpft hat, als man sofort nachverfolgen kann.

Die KanDDDinsky 2025 hat uns einen Einblick in diese Zukunft gegeben, und sie sieht vielversprechend aus: dicht, erfüllt und summend vor Ideen – genau so, wie wir es mögen. Wir freuen uns bereits darauf, diese Gespräche fortzusetzen und zu beobachten, wie diese Community die nächste Generation Event-getriebener Systeme prägt.

(rme)

Mozilla arbeitet an einer Funktion für Firefox, die Suchergebnisse künftig direkt in der Adressleiste anzeigen soll – Nutzer umgehen damit die klassische Suchmaschinen-Ergebnisseite. Das soll Anwendern nicht nur Zeit sparen, sondern gleichzeitig deren Unabhängigkeit von zentralisierten Suchmaschinen stärken. Dafür muss man jedoch gesponsorte Ergebnisse in Kauf nehmen.

Ein paar Eingaben weniger

Während herkömmliche Suchvorschläge in Browsern lediglich Vorschläge für Suchanfragen liefern, die dann zur Ergebnisseite der Suchmaschine führen, zeigt Firefox künftig direkt relevante Antworten an. Das können etwa Flugstatus-Informationen, Website-Adressen oder lokale Geschäftsempfehlungen sein. Mozilla argumentiert, dass Browser-Adressleisten heute größtenteils nur als Umweg zu Suchmaschinen dienen – das sei gut für die Anbieter von letzteren, aber nicht die Anwender.

Die technische Herausforderung lag für Mozilla im Datenschutz: Ein früherer Versuch der Funktion scheiterte: Mozilla konnte keinen Weg finden, bei dem das Unternehmen selbst nicht erfahren würde, wer wonach sucht. Anbieter von Suchmaschinen hätten ein Interesse an genau diesen Daten der Nutzer – Mozilla aber nicht.

Die jetzt entwickelte Architektur nutzt das Verschlüsselungsprotokoll Oblivious HTTP (OHTTP), an dessen Entwicklung Mozilla beteiligt war. Das Verfahren trennt systematisch die Kenntnis über die Identität des Nutzers von der Kenntnis über den Suchinhalt: Wenn Firefox eine Suchanfrage stellt, wird diese per OHTTP verschlüsselt und an einen Relay-Server geschickt, den der US-Cloud-Anbieter Fastly betreibt. Dieser Relay-Server kann die IP-Adresse des Nutzers sehen, aber nicht den verschlüsselten Suchtext.

Drei-Parteien-Modell verhindert Zuordnung

Der Relay-Server leitet die verschlüsselte Anfrage an Mozilla-Server weiter, wo sie entschlüsselt wird. Mozilla kann den Suchtext lesen, kennt aber nicht die IP-Adresse des Absenders. Anschließend kann Mozilla direkt eine Antwort liefern oder diese von spezialisierten Suchdiensten abrufen. Keine einzelne Partei kann eine Suchanfrage einer bestimmten Person zuordnen, das zumindest ist der Plan.

Firefox wird weiterhin traditionelle Suchvorschläge für alle Anfragen anzeigen und Direktergebnisse nur dann einblenden, wenn eine hohe Übereinstimmung mit der vermuteten Nutzerabsicht besteht. Ähnlich wie bei Suchmaschinen können manche dieser Ergebnisse gesponsert sein, um Firefox zu finanzieren. Allerdings betont Mozilla, dass weder das Unternehmen noch der Sponsor erfahren wird, wem die Ergebnisse angezeigt werden – und nur bei hoher Relevanz werden gesponserte Inhalte überhaupt ausgespielt.

Zunächst nur in den USA verfügbar

Die Einführung erfolgt zunächst ausschließlich in den Vereinigten Staaten, da Mozilla laut Ankündigung die Funktion im großen Maßstab testen muss. Das System erfordert ausreichende Serverkapazitäten und eine geografisch verteilte Infrastruktur, um keine spürbaren Latenzen zu verursachen. Eine Ausweitung auf andere Regionen soll auf Basis der gesammelten Erfahrungen evaluiert werden – entsprechend gibt es noch keine Angaben zu einer Verfügbarkeit in Deutschland.

Da sich die Funktion noch in der Entwicklung befindet, wird sie erst im Laufe des kommenden Jahres schrittweise eingeführt. Nutzer können die Funktion in den Firefox-Einstellungen unter „Suche“ durch Deaktivieren der Option „Vorschläge während der Eingabe abrufen“ abstellen. Wer die Funktion bereits vor der Verfügbarkeit in den Einstellungen deaktivieren möchte, kann über about:config den Parameter browser.urlbar.quicksuggest.online.enabled auf false setzen.

(fo)

Meine Verzweiflung wuchs: Nachdem ich in Auto und Smartphone ein Profil hinterlegt hatte, lieferte der A5 anderthalb Tage lang einen schwarzen Bildschirm, auf dem mir mitgeteilt wurde, dass meine Nutzerdaten überprüft würden – und zwar alternativlos, denn es gab kein Vor oder Zurück. Ich hatte schon die Notfallnummern rausgesucht, als Audi die Prüfung dann doch noch abgeschlossen hatte. Ab da lief das System störungsfrei und ziemlich flink. Letzteres gilt im Prinzip für den ganzen A5. Schon nach ein paar Kilometern kann man sich vorstellen, warum eine bestimmte Klientel genau diese Art von Auto sucht. Gleichzeitig offenbart sich rasch, warum nur wenige den A5 e-Hybrid wählen werden.

Knapp geschnitten

Mit dem Modellwechsel vom A4 zum A5 hat das Mittelklassemodell nochmals zugelegt und misst nun 4,83 m in der Länge. Gemessen daran ist das Platzangebot eher übersichtlich. Vier Erwachsene kommen noch halbwegs bequem unter, sofern keine Riesen unter ihnen sind. Doch gerade hinten ist der A5 nicht besonders großzügig geschnitten. Anekdote am Rande: Der A5 ist minimal länger als ein Audi 100 aus den 1980er-Jahren, der im Vergleich zum aktuellen Modell das Raumangebot einer Markthalle hat.

Der Kofferraum des A5 e-Hybrid fasst laut nur 331 Liter, das wäre weniger als ein VW Polo zu bieten hat. Zarte Zweifel an der Herstellerangabe seien hiermit angemeldet, denn ich maß mehr als einen Quadratmeter in der Fläche und bis zu 42 cm zwischen Boden und Abdeckung. Selbst wenn man noch ein paar Literchen abzieht, sollten mehr als 331 Liter in dieses Gepäckabteil passen. Riesig ist es freilich dennoch nicht. Hier rächt sich, dass auf einer Plattform für Verbrenner ein Plug-in-Hybrid nachträglich integriert wurde. Im A5-Benziner sind es 445 Liter, was bei den Außenabmessungen auch nicht gerade ein überzeugendes Verhältnis zwischen Platzangebot und beanspruchter Verkehrsfläche ist.

Das war die Leseprobe unseres heise-Plus-Artikels „Audi A5 e-Hybrid im Test: Rasant, und ohne Aussicht auf breiten Erfolg“.
Mit einem heise-Plus-Abo können Sie den ganzen Artikel lesen.