In Lektion 2.14.1 stand der Buchungsendpunkt der Kladde ganz oben auf der Liste der Umbauten: 68 Zeilen in einer Methode, neun Parameter, eine zyklomatische Komplexität von 12, und eine eigene Fassung der Regel, wann das Büro Buchungen annimmt. In dieser Lektion bauen Sie ihn um. Am Ende prüft ein Unit-Test die Buchung in wenigen Millisekunden, ohne Datenbank und ohne Webserver, und die Leitung bekommt ihre Samstagvormittage mit einer einzigen Änderung.
Was „eine Verantwortung“ heißt
Das S in SOLID steht für das Single-Responsibility-Prinzip: Eine Klasse hat eine Verantwortung. Das klingt nach „eine Klasse tut eine Sache“, und so verstanden führt es in die Irre. Auch eine Methode mit fünf Zeilen tut, genau betrachtet, fünf Dinge.
Brauchbarer ist die Frage, wer eine Änderung verlangt. Eine Verantwortung ist ein Grund zur Änderung, und hinter jedem Grund steht jemand. Gehen Sie den Endpunkt aus Lektion 2.14.1 so durch:
| Teil des Endpunkts | Wer verlangt eine Änderung? | Beispiel |
|---|---|---|
// check: Öffnungszeiten, Vorlauf |
das Büro | „Samstags vormittags auch.“ |
// book: speichern, Doppelbuchung |
die Fachlichkeit der Kladde | „Zwei Termine dürfen sich nicht überschneiden.“ (gibt es schon im Kern) |
// notify: Mail, Webhook, Live-Anzeige |
Kundschaft, Partner, das Büro | „Ein vierter Weg: das Aktivitätsprotokoll.“ |
// log |
der Betrieb | „Die Zeile braucht die Dauer.“ |
| Statuscodes, ProblemDetails, Route | wer die API aufruft | „Ein 409 soll einen eigenen type haben.“ (Lektion 2.12.1) |
Fünf Gruppen von Menschen, fünf Gründe. Jede Änderung, die eine von ihnen verlangt, fasst dieselbe Methode an, und jedes Mal kann etwas an den vier anderen Stellen kaputtgehen. Das ist der Schmerz.
Der Umbau trennt die Teile so, dass jeder Grund an einem Ort landet:
- Die Regel steht schon im Kern:
BookingRulesundFreeSlotsaus Lektion 2.5.6. Der Endpunkt muss sie nur benutzen statt nachbauen. - Der Anwendungsfall „einen Termin buchen“ kommt als eigene Klasse in den Kern. Er fragt die Regel, bucht und sagt Bescheid. Er kennt weder HTTP noch Mail.
- Die Benachrichtigung bekommt einen Port im Kern,
IBookingNotifier, und eine Umsetzung am Rand, die Outbox, Webhook und Hub kennt. - Dem Endpunkt bleibt HTTP: die Anfrage herein, das Ergebnis des Anwendungsfalls als Statuscode hinaus.