Customer Red–Green–Refactor
Vom fehlenden HTTP-Endpunkt zu Value Objects, Fehlercodes und lesbaren Testdaten.
Customer Red–Green–Refactor
Zyklus 1 – äußerer Akzeptanztest
Red POST /api/v1/customers existierte nicht.
Green Handler, Use Case, deterministische ID und In-Memory-Repository lieferten HTTP 201.
Refactor HTTP-Parsing und fachliche Registrierung wurden getrennt.
Zyklus 2 – eindeutige E-Mail-Adresse
Red dieselbe E-Mail-Adresse konnte mit anderer Groß-/Kleinschreibung mehrfach gespeichert werden.
Green EmailAddress normalisiert den Wert; das Repository sucht über den typisierten Wert.
Refactor Der Normalisierungscode wurde aus Handler und Use Case in das Value Object verschoben.
Zyklus 3 – ungültige Daten
Red ungültige E-Mail-Adressen führten nur zu einem generischen Fehler.
Green Der Use Case übersetzt Validierungsfehler in CustomerDataInvalidException; der Adapter liefert CUSTOMER_DATA_INVALID.
Refactor Fehlerbedeutung und HTTP-Status wurden getrennt.
Zyklus 4 – lesbare Testdaten
Red wiederholte Rohstrings verschleierten die fachlich relevante Abweichung.
Green CustomerTestDataBuilder liefert gültige Standarddaten.
Refactor Tests benennen nur noch die jeweils abweichende Eigenschaft.
Ergebnis
Alle drei gemeinsamen Customer-Szenarien laufen über denselben realen HTTP-Pfad. Es wird genau ein Kunde gespeichert und genau ein CustomerRegisteredEreignis veröffentlicht.