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)

Die Open-Source-Runtime Wasmer ist in Version 7.0 mit neuen Funktionen für Python, RISC-V und zahlreichen Bugfixes erschienen. Insgesamt hat das Entwicklungsteam 200 Pull-Requests umgesetzt – davon 80, die sich auf Bugs oder seit Langem bestehende Limitierungen bezogen.

Das auf WebAssembly basierende Wasmer-Ökosystem ermöglicht das Ausführen von Anwendungen im Browser, eingebettet in eine Programmiersprache nach Wahl oder standalone auf dem Server.

Version 7.0 erweitert den Python-Support

In Wasmer 7.0 ist eine experimentelle Async-API mit an Bord, verfügbar in Wasmers nativen Backends singlepass, cranelift und llvm. Die API ermöglicht vollständigen Async-Support in Python unter Wasmer, was das Verwenden von Bibliotheken wie SQLAlchemy ermöglicht. Darüber hinaus bietet Wasmer 7.0 Support für dynamisches Linking in WASIX. Bislang war der Python-Support in Wasmer auf den Core Intepreter beschränkt, sodass sich viele native Libaries, beispielsweise NumPy, nicht nutzen ließen.

Weitere Updates betreffen unter anderem RISC-V: Die CPU-Befehlssatzarchitektur war in Wasmer bereits in LLVM und Cranelift verfügbar, doch nun besitzt auch Singlepass RISC-V-Support. Zudem ist das LLVM-Target RV32gc für eine erhöhte RISC-V-Abdeckung hinzugekommen.

Details zum neuen Release finden sich in der Ankündigung im Wasmer-Blog. Zusätzliche Informationen zu den neuen Python-Features sollen in weiteren Blogbeiträgen folgen.

(mai)