Abend 2: Die langweiligen Anforderungen
Der zweite Abend galt allem, was in Präsentationen fehlt und in echten Projekten Monate frisst: API-Verträge, Kundenaufträge nach Swiss Payment Standards, austauschbare Transporte, zwei Datenbanken und mehrere Instanzen. 29 Commits.
Warum das Unspektakuläre zählt
Ein Prototyp beeindruckt mit der Oberfläche. Ein produktives System muss mit dem leben, was um es herum steht: Kanäle, die Aufträge liefern. Ein Buchungssystem, das Ergebnisse braucht. Eine Bank, die Oracle betreibt, und eine andere, die PostgreSQL will. Ein Betrieb, der mehrere Instanzen parallel fährt.
In klassischen Projekten sind das die Arbeitspakete, an denen Zeitpläne scheitern. Sie sind fachlich wenig aufregend, aber jedes hat seine Tücken.
Was an diesem Abend entstand
| Thema | Ergebnis |
|---|---|
| API-Verträge | OpenAPI-Verträge für alle Services, die Oberfläche bezieht ihre Typen daraus |
| Kundenaufträge | pain.001 und pain.002 nach SPS 2026, Prüfung, Duplikaterkennung, Quittung und Status |
| Integration | Austauschbare Transporte: Kafka, JMS, HTTP, Datei. Ausgangspostfach mit Wiederholungen und Fehlerablage |
| Buchungen | Ereignisse an das Buchungssystem, Wiederholung nach dem Ergebnis einer Zahlung |
| Persistenz | Zahlungen, Prüfpfad, Aufträge, Rückforderungen und Freigaben in PostgreSQL oder Oracle |
| Betrieb | Mehrere Instanzen auf einer Datenbank, gemeinsame Limiten pro Kanal |
| Kanalverwaltung | Register der Kanäle mit Vier-Augen-Freigabe |
Der Moment, in dem Erfahrung zählt
Ein Beispiel: Wenn zwei Instanzen gleichzeitig laufen, darf eine Zahlung nicht zweimal verarbeitet werden. Ein Agent baut auf Nachfrage eine Sperre. Ob die Sperre auch hält, wenn eine Instanz mitten in der Verarbeitung abstürzt, fragt er nicht von sich aus.
Genauso beim Limit pro Kanal. Zählt jede Instanz für sich, kann ein Kanal das Limit mehrfach ausschöpfen. Das fällt im Test nicht auf, erst in der Produktion.
Solche Fragen kommen nicht aus dem Code. Sie kommen aus Vorfällen, die man erlebt hat.
Ein Detail mit Wirkung
Die Agenten haben zwei Datenbanken parallel implementiert und gegen beide getestet, Oracle auf einem eigenen Rechner. In einem Projekt mit Team wäre das ein eigenes Arbeitspaket mit Abstimmung, Testumgebung und vermutlich der Entscheidung, Oracle «später» zu machen. Hier war es ein Pull Request.
Die Erkenntnis des Abends
Die Arbeit, die in Projekten am meisten Zeit kostet, ist für Agenten die einfachste: gut definiert, oft gemacht, gut dokumentiert. Die schwierigen Stellen bleiben dieselben wie früher, nur sind sie jetzt das Einzige, was übrig bleibt.