Der Reise-Butler ist die Smartphone-App für den wissbegierigen Reisenden und Fallbeispiel für die Methode CARDS+.


Heute wollen sie die Grundlagen für das nächste Produktinkrement schaffen. Nach der Aufteilung in zwei Arbeitsgruppen letzte Woche ist die Definition der internen Schnittstellen für die Datenflüsse für eine störungsfreie und effiziente Zusammenarbeit besonders wichtig. Um dieses Ziel zu erreichen, müssen sie jeden Datenfluss zwischen den Komponenten des Systems als Event mit dem gleichnamigen Baustein von CARDS+ im Wiki fachlich und technisch spezifizieren.

Moritz regt eine gemeinsame Design-Session, mit einer Timebox von 45 Minuten für jedes Event, an. Alle sollen teilnehmen. « Der Schwerpunkt liegt auf der fachlichen Beschreibung. Zuerst brauchen wir einen guten Namen für das Event. Dann müssen wir ein gemeinsames Verständnis von Sinn und Zweck entwickeln. Zuletzt erst definieren wir mit Avro die Struktur. »

Beginnen wollen sie mit einem Event für die Aufnahme von Daten aus dem Internet. Den Namen haben sie schnell gefunden. Der Begriff “Punkt” stand ja schon länger fest. Mit dem Zusatz “daten” wollen sie ausdrücken, dass sie an dieser Stelle offen für jede Art von Datenquellen sind.

Bevor sie sich über die Eigenschaften des Events unterhalten, legt Moritz eine entsprechende Seite im Wiki an. Dafür nutzt er den Baustein Event. Logisch. Für jeden gut lesbar an die Wand projiziert schreibt Moritz in kurzen, prägnanten Sätzen mit, was ihnen einfällt. Mehrfach ändern sie die Formulierung oder streichen einen Satz, bis alle zufrieden sind.

Mit dem Event Punktdaten kann jeder Datensatz einer Quelle im Internet kompakt beschrieben werden. Der Event ist so ausgelegt, dass immer nur eine Sprache geliefert wird. Mehrsprachigkeit können sie so schrittweise einführen.

Erst das Schema macht die Dokumentation des Events vollständig. Julius kennt Avro bereits. Aus diesem Grund löst er Moritz am Rechner ab und tippt das Schema für alle sichtbar in einen JSON-Editor ein. Gemeinsam definieren sie die Struktur des Events mit primitiven und komplexen Typen und Listen. Mit einem doc-Element erfasst Julius Einschränkungen des Wertebereichs oder andere Hinweise. Bei optionalen Attributen mit primitiven Typen verwendet er das default-Element, um einen passenden Null-Wert für die Schema-Evolution zu definieren. Das default-Element ist dadurch ein Teil der Dokumentation und eine wichtige Ergänzung zum doc-Element.

Nach einer kurzen Pause machen sie mit dem zweiten wichtigen Event für den Datenfluss vom Backend in die Assistenz weiter. Dieses Event ist die größere Herausforderung, weil sie ganz wesentlich die Zusammenarbeit der beiden Gruppen beeinflusst.

Den Namen für das Event finden sie wieder sehr schnell. Der Begriff “Punkt” ist auch hier gesetzt. Der Zusatz “kontext” hebt den Verzicht auf ein Differenzprotokoll hervor. Ein ganz wichtiger nicht funktionaler Aspekt für Moritz. Eine kurz aufflammende Diskussion unterbindet er mit dem Hinweis, dass sie sich sowieso noch mit einem Gesamtkonzept für Events beschäftigen müssen. Aber nicht jetzt.

Der Aufbau von Event Punktkontext ist weitestgehend technisch motiviert. Bei asynchroner Datenverarbeitung spielt die Reihenfolge der Events eine wichtige Rolle. Es lässt sich durch geeignete Partitionierung der Topics sicherstellen, dass sich Events nicht überholen. Da es wegen der Schema-Registry nur einen Event-Typ je Kafka-Topic geben darf, ergibt sich dieser Event. Ein weiterer wichtiger Punkt ist die Vermeidung der Übertragung von aufeinander aufbauender Differenzen. Bei so einem Vorgehen ist schon der Verlust eines einzigen Events ein schwerwiegendes Problem. Darum enthält der Event Punktkontext immer alle Daten, die es zu diesem Punkt gibt. Dadurch ist der Verlust eines Events eher unkritisch bzw wird mit der nächsten Änderung der Daten automatisch korrigiert.

Das Schema für dieses Event ist etwas mehr Tipparbeit aufgrund der Listen mit den komplexen Typen für Station, Dienst, Objekt und Termin. Die Timebox hat nicht gereicht, um das Event vollständig mit Avro zu spezifizieren. Julius bietet an, das Schema alleine fertigzustellen. Den Vorschlag nehmen die anderen Studenten gerne an. Sie sehen kein Risiko. Die Struktur jedes Listenelementes ergibt sich direkt aus der Beschreibung in der entsprechenden Entity im Wiki, die sie schon vor einiger Zeit abgestimmt hatten.

Mit den beiden Events haben sie eine gute Grundlage für die kommenden Aufgaben geschaffen. Die Aufgaben wird Moritz im Laufe der Woche in JIRA anlegen und aus seiner Sicht als Product-Owner priorisieren. Die Motivation im Team ist groß, endlich richtig loslegen zu können. Weil sie sich vor Wochen darauf geeinigt haben, Farben zu verwenden, legen sie den Codenamen BLAU für das zweite Produktinkrement fest.

« Apropos Codenamen: Habt ihr über Namen für eure Arbeitsgruppen nachgedacht? »

Schnell wird klar, dass sie Moritz’ Vorschlag von letzter Woche entweder nicht ernst genommen (Tim?) oder schlicht vergessen haben. Einen Versuch will Moritz jedoch noch machen. Weil er schon länger die Absicht hatte, das Team aufgrund ihrer guten Leistung zum Essen einzuladen, schlägt er Mittagessen beim Italiener um die Ecke vor. Dort haben sie Gelegenheit, noch einmal über Namen nachzudenken. Entweder sie finden welche, oder es bleibt bei Gruppe eins und zwei. Basta.

Zuletzt veröffentlichte Beiträge: