In dieser Episode spricht Richard Seidl mit Daniel Krauss, dem Gründer von Flix, und Florian Fieber, aktiv im German Testing Board e.V. (GTB), über Qualität und Testen in Start-ups. Sie vergleichen B2C und B2B, diskutieren schnelle Lieferzyklen, knappe Budgets und warum Qualität kein Selbstzweck ist. Ausfälle kosten mehr als gutes Testen, Coverage ist Mittel, nicht Ziel.

Über Daniel Krauss und Florian Fieber

Als Chief Information Officer (CIO) und Chief HR Officer (CHRO) bei Flix ist Daniel Krauss für die Bereiche Technologie und Personal des Unternehmens verantwortlich. Zusammen mit seinen Mitbegründern hat er Flix zu einem internationalen Transportdienstleister ausgebaut. Daniel Krauss ist außerdem Investor und Beiratsmitglied in Unternehmen wie BabyOne, Unity und GWF. Er ist überzeugt, dass Bildung, Unternehmertum und Innovation die Gesellschaft maßgeblich voranbringen können.

Florian Fieber studierte Medieninformatik und Information Systems, danach war er als Softwareentwickler und wissenschaftlicher Mitarbeiter tätig. Sein Fachgebiet umfasst heute alle Aspekte der Qualitätssicherung im Softwarelebenszyklus, mit einem Schwerpunkt auf Testmanagement und Prozessverbesserung. Seit 2018 ist er aktiv im German Testing Board e. V. (GTB), wo er unter anderem als Leiter der Arbeitsgruppe Acceptance Testing fungiert und seit 2022 als Vorsitzender des GTB dient.

Bei diesem Podcast dreht sich alles um Softwarequalität: Ob Testautomatisierung, Qualität in agilen Projekten, Testdaten oder Testteams – Richard Seidl und seine Gäste schauen sich Dinge an, die mehr Qualität in die Softwareentwicklung bringen.

Die aktuelle Ausgabe ist auch auf Richard Seidls Blog verfügbar: „Testen und Qualitätssicherung bei Start-ups – Daniel Krauss, Florian Fieber“ und steht auf YouTube bereit.

(mdo)

Wenn Entwicklerinnen und Entwickler zum ersten Mal mit Domain-Driven Design (DDD), CQRS und Event Sourcing in Berührung kommen, bringen sie bereits mentale Modelle mit. Jahre der Arbeit mit Objekten und Tabellen haben geprägt, wie sie über Daten denken.

Und so haben sie sofort ein vertrautes Bild im Sinn, wenn sie das Wort „Aggregat“ hören: Ein Aggregat muss wie ein Objekt sein, und Objekte werden auf Tabellen abgebildet. Diese Intuition fühlt sich richtig an. Aber: Sie ist es nicht, und sie führt zu einem System, das verdächtig nach CRUD mit zusätzlichen Schritten aussieht.

Ich habe dieses Muster unzählige Male gesehen. Teams bauen etwas, das sie ein Event-getriebenes System nennen, und landen bei einer einzelnen books-Tabelle, die jedes Feld enthält, das ihr Book-Aggregat hat. Sie haben im Grunde eine relationale Datenbank nachgebaut, nur mit Events als Transportmechanismus. Die Stärken von DDD, CQRS und Event Sourcing, also die Flexibilität, die diese Konzepte versprechen – all das bleibt ungenutzt.

Das Aggregat-Missverständnis

Das Problem ist das, was Entwicklerinnen und Entwickler typischerweise für ein Aggregat halten: einen Container für alle Daten über eine Sache. Sie stellen sich ein Book-Aggregat vor und beginnen, Eigenschaften aufzulisten:

BookAggregate {
    id: string
    title: string
    author: string
    isbn: string
    currentBorrower: string | null
    dueDate: Date | null
    location: string
    condition: string
    purchasePrice: number
    acquisitionDate: Date
    lastInspectionDate: Date
    popularityScore: number
}

Das sieht aus wie ein Objekt. Es hat alle Felder. Es lässt sich sauber auf eine Datenbanktabelle abbilden. Und genau darin liegt der Fehler: das Aggregat als Daten-Container zu behandeln.

Wenn Sie so denken, wird Ihr Aggregat zu einer aufgeblähten Repräsentation von allem, was Sie jemals über ein Buch wissen wollen könnten. Es spiegelt die Struktur Ihres Read Model wider, weil Sie noch nicht erkannt haben, dass es grundlegend verschiedene Konzepte sind, die grundlegend verschiedene Zwecke erfüllen.

Was ein Aggregat tatsächlich ist

Gemäß DDD ist ein Aggregat eine Konsistenzgrenze für die Entscheidungsfindung. Das ist alles. Sein Zweck ist sicherzustellen, dass Geschäftsregeln eingehalten werden, wenn Commands verarbeitet werden. Es benötigt nur die Informationen, die erforderlich sind, um zu entscheiden, ob ein Command gültig ist.

Betrachten Sie das BorrowBook-Command. Um zu entscheiden, ob ein Buch ausgeliehen werden kann, müssen Sie nur eins wissen: Ist das Buch derzeit verfügbar? Sie brauchen nicht den Titel, die Autorin oder den Autor, die ISBN, den Kaufpreis, den Standort oder das letzte Inspektionsdatum. Keine dieser Informationen hilft Ihnen zu entscheiden, ob dieses spezifische Command erfolgreich sein sollte oder nicht. Das heißt, das Aggregat kann sehr schlank sein, denn es enthält nur den entscheidungsrelevanten Zustand.

Für unser Bibliotheksbeispiel könnte ein richtig entworfenes Book-Aggregat daher folgendermaßen aussehen:

BookAggregate {
    isAvailable: boolean
    currentBorrower: string | null
}

Das reicht aus, um zu entscheiden:

• Kann dieses Buch ausgeliehen werden? (isAvailable === true)
• Kann diese Person es zurückgeben? (currentBorrower === personId)

Alles andere, jede andere Information über das Buch, gehört woanders hin – und zwar in Read Models, nicht in das Aggregat.

Das Read-Model-Missverständnis

Sobald Entwicklerinnen und Entwickler akzeptieren, dass ein Aggregat bestimmte Felder hat, folgt der nächste Fehler: „Wenn mein Aggregat diese Felder hat, sollte meine Read-Model-Tabelle diese Felder auch haben.“

Das Ergebnis ist vorhersehbar. Sie erstellen eine books-Tabelle mit Spalten für id, title, author, isbn, borrower, dueDate, location, condition, purchasePrice und jedes andere Feld, das Ihnen einfällt. Abfragen werden zu komplexen Joins über diese monolithische Struktur. Die Performance leidet. Die Flexibilität verschwindet.

Das ist CRUD-Denken, angewandt auf Event Sourcing. Die Events existieren, aber sie sind nur eine Transportschicht. Das System dreht sich immer noch um eine einzelne kanonische Repräsentation der Daten, genau wie eine traditionelle relationale Datenbank.

Was Read Models tatsächlich sind

Read Models sind Projektionen, die für spezifische Abfragen optimiert sind. Sie dienen Anwendungsfällen, nicht Datenstrukturen. Und hier ist die entscheidende Erkenntnis: Read Models werden aus Events abgeleitet, nicht aus Aggregaten:

• Ihr Aggregat entscheidet, was passiert.
• Events zeichnen auf, was passiert ist.
• Read Models werden aus diesen Events gebaut, um spezifische Fragen effizient zu beantworten.

Es gibt keine Anforderung, keine Regel, kein architektonisches Prinzip, das besagt, dass Read Models die Struktur von Aggregaten spiegeln müssen.

Tatsächlich ist das Gegenteil wahr. Aus einem Event-Stream können Sie viele verschiedene Read Models bauen. Das ist die Stärke von CQRS, die verloren geht, wenn Sie in Tabellen denken.

Das Bibliotheksbeispiel: Ein Write Model, viele Read Models

Machen wir das konkret mit unserer Bibliothek. Wir haben ein Book-Aggregat, das Entscheidungen handhabt:

BookAggregate {
    isAvailable: boolean
    currentBorrower: string | null
}

Events fließen durch das System: BookAcquired, BookBorrowed, BookReturned, BookRemoved und so weiter. Diese Events enthalten reichhaltige Informationen darüber, was passiert ist.

Betrachten Sie nun die verschiedenen Fragen, die Menschen beantwortet bekommen möchten:

• Die Katalogsuche muss verfügbare Bücher mit ihren Titeln, Autorinnen und Autoren sowie ISBNs zeigen. Sie interessiert sich nicht für die Ausleihhistorie oder den physischen Standort.
• Das Mitglieder-Dashboard (die „Meine Bücher“-Seite) muss zeigen, welche Bücher das Mitglied ausgeliehen hat, wann sie fällig sind und ob welche überfällig sind. Es braucht keine ISBNs oder physische Standorte.
• Das Statistik-Panel für Bibliothekarinnen und Bibliothekare muss wissen, welche Bücher am beliebtesten sind, durchschnittliche Ausleihdauern und Trends über die Zeit. Es braucht nicht die aktuelle Verfügbarkeit.
• Der Überfällig-Bericht benötigt Namen der Ausleihenden, Kontaktinformationen, Buchtitel und wie viele Tage überfällig. Er benötigt keine Kaufpreise oder Zustandsbewertungen.
• Das Bestandsverwaltungssystem benötigt physische Standorte, Zustandsbewertungen und letzte Inspektionsdaten. Es braucht keine Informationen über Ausleihende.

Jedes davon ist ein separates Read Model, gebaut aus denselben Events, optimiert für seinen spezifischen Anwendungsfall.

Viele kleine Read Models statt einer großen Tabelle

So könnten diese Read Models aussehen:

Katalogsuche-Read-Model:

{
    bookId: string
    title: string
    author: string
    isbn: string
    isAvailable: boolean
}

Ausleihenden-Dashboard-Read-Model:

{
    memberId: string
    books: [
        {
            bookId: string
            title: string
            dueDate: Date
            daysOverdue: number
        }
    ]
}

Bibliotheksstatistik-Read-Model:

{
    bookId: string
    title: string
    totalBorrows: number
    averageDuration: number
    popularityRank: number
}

Überfällige-Bücher-Read-Model:

{
    bookId: string
    title: string
    borrowerId: string
    borrowerName: string
    contactEmail: string
    daysOverdue: number
}

Bestands-Read-Model:

{
    bookId: string
    location: string
    condition: string
    lastInspectionDate: Date
}

Jedes Read Model

• hat nur die Felder, die für seinen Anwendungsfall benötigt werden,
• kann bei Bedarf in einer anderen Datenbank gespeichert werden (PostgreSQL für Transaktionen, Elasticsearch für Suche, Redis für schnelle Lookups),
• kann jederzeit aus Events neu aufgebaut werden und
• entwickelt sich unabhängig von anderen Read Models weiter.

Der Multiplikationseffekt

Hier zeigt Event Sourcing seine wahre Stärke. Aus einem Stream von Events leiten Sie viele spezialisierte Read Models ab. Jedes ist klein, fokussiert und schnell. Das Hinzufügen eines neuen Read Model erfordert keine Änderung des Write Model oder bestehender Read Models. Sie bauen einfach eine weitere Projektion aus denselben Events.

Brauchen Sie einen neuen Bericht? Erstellen Sie ein neues Read Model. Müssen Sie eine langsame Abfrage optimieren? Strukturieren Sie dieses spezifische Read Model um, ohne irgendetwas anderes anzufassen. Müssen Sie einen neuen Anwendungsfall unterstützen? Fügen Sie eine weitere Projektion hinzu.

Diese Flexibilität ist das Versprechen von CQRS. Aber sie materialisiert sich nur, wenn Sie aufhören, Read Models als Spiegel Ihrer Aggregate zu betrachten.

Warum das wichtig ist

Die praktischen Vorteile sind erheblich:

• Die Performance verbessert sich, weil jedes Read Model klein und spezialisiert ist. Abfragen treffen genau die Daten, die sie brauchen, nicht mehr. Indizes können für spezifische Zugriffsmuster optimiert werden.
• Die Flexibilität steigt, weil Sie Read Models hinzufügen, modifizieren oder entfernen können, ohne das Write Model oder andere Read Models zu beeinflussen. Teams können ihre Read Models unabhängig besitzen.
• Klarheit entsteht, weil jedes Read Model einen klaren Zweck hat. Es gibt keine Mehrdeutigkeit darüber, welche Daten für welchen Anwendungsfall sind. Die Struktur jedes Read Model reflektiert die Fragen, die es beantwortet.
• Unabhängigkeit folgt, weil verschiedene Teams an verschiedenen Read Models arbeiten können, ohne Schemaänderungen koordinieren zu müssen. Die Events sind der Vertrag, nicht die Datenbanktabellen.

Die Tabelle verlernen

Der schwierigste Teil von Event Sourcing ist das Verlernen der mentalen Modelle, die Ihnen in CRUD-Systemen gute Dienste geleistet haben. Objekte und Tabellen sind nützliche Konzepte, aber sie sind nicht die richtige Linse, um Aggregate und Read Models zu verstehen.

Hören Sie auf zu fragen: „Welche Felder hat mein Aggregat?“ Beginnen Sie zu fragen: „Was muss ich wissen, um diese Entscheidung zu treffen?“

Hören Sie auf zu fragen: „Welche Tabelle brauche ich für dieses Aggregat?“ Beginnen Sie zu fragen: „Welche Fragen müssen meine Nutzerinnen und Nutzer beantwortet bekommen?“

Das Aggregat ist Ihre Entscheidungsgrenze, schlank und fokussiert. Events sind Ihre historische Aufzeichnung dessen, was passiert ist. Read Models sind Ihre optimierten Sichten für spezifische Abfragen.

Das sind drei verschiedene Konzepte. Sie müssen nicht dieselbe Struktur haben. Tatsächlich sollten sie es wahrscheinlich nicht.

(rme)

Das Unternehmen Dynatrace hat im Rahmen seiner alljährlichen Perform-Konferenz einen erweiterten Ansatz für den Einsatz künstlicher Intelligenz für Observability-Aufgaben vorgestellt. Das neue Modul hört auf den Namen Dynatrace Intelligence (DTI) und baut im Wesentlichen auf schon bekannten Technologien und Verfahren auf – nun ergänzt um KI-Agenten.

KI ist für die Observability-Plattform von Dynatrace nichts Neues. Schon seit Jahren nutzt der Anbieter eine deterministische Variante dieser Technologie, die auf einer Fehlerbaum-Analyse basiert und Problemursachen sowie Abhängigkeiten präzise ermittelt. Mit Dynatrace Intelligence kommt nun die Agenten-basierte KI hinzu. Das Fundament bilden dabei die schon bekannten Module Grail und Smartscape. Ersteres enthält von Dynatrace gesammelte Daten und bildet damit die Grundlage für alle Analysen und Bewertungen. Diese „Datenbank“ wird ergänzt durch den Abhängigkeitsgraph Smartscape, den Dynatrace nun für DTI noch erweitert hat.

Laut Ankündigung kann die Plattform jetzt auch geschäftliche Informationen und andere nicht technische Meta-Daten aufnehmen und verarbeiten. Zudem habe Dynatrace nochmals an der Leistungsschraube gedreht. Mit „Historical Replay“ – einer Art Zeitmaschine – lassen sich Fehlerereignisse jetzt so analysieren, als würden sie gerade passieren. Zur Interaktion mit anderen Anwendungen wie etwa Slack, AWS DevOps oder Azure SRE kommt ein eigener MCP-Server zum Einsatz – der jedoch nicht zwingend erforderlich ist. Dynatrace-Kunden können auch eigene, selbst-entwickelte MCP-Server nutzen.

Neu in Dynatrace Intelligence sind ab sofort auch Agenten (siehe Abbildung). Sie unterteilen sich in vier Kategorien. Da sind zunächst die deterministischen Agenten: einer für die Problemursache, einer für allgemeine Analysen und einer für Vorhersagen. Die zweite Kategorie umfasst die Ökosystem-Agenten, die für die Interaktion mit externen Anwendungen und/oder Daten zuständig sind. Beide Kategorien sind per se nicht neu. Dynatrace stellt lediglich das vorhandene Wissen und die Erfahrung in Form von agentenbasierter KI zur Verfügung. Die Expertise zu bestimmten Gebieten wie IT-Sicherheit, Site Reliability Engineering (SRE) oder Softwareentwicklung liegt bei den Domänen-Agenten. Der Operater-Agent und der Assist-Agent runden das Bild ab. Ersterer ist für die Verwaltung der DIT-Komponenten zuständig. Der Name ist dabei nicht zufällig gewählt, sondern verweist auf die bekannte Kubernetes-Methode zum Bereitstellen und Warten von Anwendungen. Der Kontext des Assist-Agenten ist die Chatbox-Funktion der Observability-Plattform.

Auf den ersten Blick erscheint die technische Umsetzung von Dynatrace Intelligence einfach. Grail und Smartscape gab es schon. Im Bereich agentenbasierter KI und MCP hat sich 2025 ebenfalls schon viel getan. Doch ganz so einfach ist es nicht: Bernd Greifeneder, Mitbegründer und CTO von Dynatrace, erklärt im Gespräch mit heise developer, dass insbesondere die Kombination der Ergebnisse der verschiedenen KI-Ansätze eine Herausforderung darstellte. Nun aber könne Dynatrace versprechen, dass die deterministische Künstliche Intelligenz verlässliche Antworten liefere.

Die Problematik des Ratens oder Halluzinierens bei KI-Modellen bleibt, dies dürfte sich auch durch die Verwendung der KI-Agenten nicht ändern. Welche Rolle der MCP-Server in der Praxis spielen kann, bleibt abzuwarten. Grail und Smartscape sind darauf ausgelegt, auch größere Datenmengen schnell verarbeiten zu können. Der MCP-Server könnte sich hier als Flaschenhals erweisen. Daher lautet die Empfehlung, die Observability-Plattform möglichst über die nativen Integrationen mit Informationen zu füttern und den MCP-Server nur für eher kleinere Datenmengen zu verwenden.

Vom reaktiven hin zum autonomen IT-Betrieb

Die Entwicklung von DTI ist für Dynatrace mehr als eine Reaktion auf den generellen KI-Hype. Laut Steve Tack, Chief Product Officer, sei es die nun anstehende Stufe in der Entwicklung vom anfänglich noch reaktiven Betrieb, über den proaktiven hin zum autonomen Betrieb von IT-Landschaften. Zwar mache Dynatrace nun einen fundamentalen Schritt, ein komplett automatisierter Betrieb inklusive Fehlerbehebung, Codeanpassung oder Schwachstellenbeseitigung sei zum gegenwärtigen Zeitpunkt aber noch Zukunftsmusik.

Viele Kunden des Unternehmens arbeiten derzeit noch daran, die finale Qualitätssicherung primär durch Menschen sicherzustellen. Auch hat die gesamte Branche noch signifikanten Lernbedarf bezüglich des verantwortungsvollen Umgangs mit KI. Wer sich jedoch den autonomen Betrieb als Ziel setzt, sollte sich drei Fragen stellen – und diese positiv beantworten können: Kann ich es automatisieren? Kann ich es tiefgehend überwachen? Verstehe ich in Echtzeit, was vorgeht?

Gespräche mit Kunden und deren Rückmeldungen während der Perform-Konferenz spiegeln wider, dass Dynatrace mit DTI einen vielversprechenden Entwurf vorgelegt hat. Das Modul wirkt bereits rund und ausgereift.

(map)