Decisions

Entscheidungen

Qualität als eigenständiges Modul und getrennte Profile · 12. Juli 2026

Entscheidung Architekturtests und Test-Suite-Fitness-Functions liegen in tdd-quality. Schnelle Tests, vollständige Qualitätsgates und Mutation Testing bleiben getrennte Buildpfade.

Begründung Der tägliche Red–Green–Refactor-Zyklus bleibt schnell, während CI und Abschlussläufe strengere Gates erzwingen.

technische Abhängigkeiten bleiben außerhalb des Fachkerns · 12. Juli 2026

Entscheidung JDBC, Kafka-Client, PostgreSQL-Treiber und Testcontainers sind ausschließlich im Adaptermodul erlaubt.

Begründung Die durch TDD entstandenen Ports bleiben stabil und können weiterhin mit Fakes getestet werden.

Result Type und Compensating Transaction

Carrierablehnung ist ein fachliches Resultat; technische Nichterreichbarkeit bleibt eine technische Ausnahme. Permanente Ablehnung fordert explizit eine Kompensation an.

12. Juli 2026

Fachliche Ablehnung wird nicht wiederholt. Technischer Retry wird ausschließlich durch eine Strategy entschieden. Test Doubles bleiben Stub/Spy statt interaktionslastiger Mock-Ketten.

12. Juli 2026 –: Atomarität über TransactionRunner

Der Use Case formuliert eine gemeinsame Transaktionsgrenze als Port. Das In-Memory-Fake serialisiert fair; ein späterer Persistenzadapter kann dieselbe Semantik technisch anders erfüllen.

12. Juli 2026 –: Package-Slices behalten, Übersetzungsgrenzen schärfen

Customer und Catalog werden über schmale Ordering-Ports eingebunden. Eine Maven-Modultrennung bleibt bis nach Inventory und Payment offen.

12. Juli 2026 –: Product Catalog noch nicht extrahieren

Der Katalog bleibt als vertikaler Package-Slice im vorhandenen Modul. Die physische Modulgrenze wird erst nach dem Place-Order-Slice anhand tatsächlicher Abhängigkeiten entschieden.

12. Juli 2026 –: Noch keine zusätzliche Maven-Modulgrenze

Customer entsteht zunächst als vertikaler Package-Slice im vorhandenen Modul. Eine physische Trennung wird erst nach weiteren Slices anhand realer Änderungs- und Abhängigkeitsmuster bewertet.

12. Juli 2026 – Ein Modul bleibt bestehen

Die erste ausführbare Lösung wird nicht vorsorglich auf mehrere Maven-Module verteilt. Neue Modulgrenzen benötigen späteren Test- oder Änderungsdruck.

12. Juli 2026 –: TDD-Grundentscheidungen

ADR-T9-01 – TDD ist Entwicklungsweg, nicht Architekturbezeichnung

Entscheidung Die spätere Modulstruktur wird aus Verhalten und Refactoring entwickelt. Sie wird im entsprechenden Kapitel nicht vorweggenommen.

Begründung TDD beschreibt den Entstehungsprozess. Eine vorab kopierte Layered- oder DDD-Struktur würde den Vergleich verfälschen.

ADR-T9-02 – Outside-in beginnt bei gemeinsamen Akzeptanzszenarien

Entscheidung Jeder fachliche Entwicklungsabschnitt startet an einem bereits definierten extern beobachtbaren Szenario.

Begründung Alle drei Projekte müssen dieselbe Fachlichkeit erfüllen und anhand derselben Nachweise vergleichbar bleiben.

ADR-T9-03 – Fakes vor Mock-Kaskaden

Entscheidung Repositories, Uhr und andere frühe Grenzen werden bevorzugt als semantische Fakes umgesetzt. Mocks bleiben konkreten ausgehenden Nachrichten vorbehalten.

Begründung Fakes stützen Verhaltensdesign und vermeiden eine Kopplung der Tests an interne Aufrufreihenfolgen.

ADR-T9-04 – Kein Produktionscode im entsprechenden Kapitel

Entscheidung Dieses Kapitel erzeugt Strategie, Reaktor und Nachweisstruktur. Der erste Produktionspfad beginnt im nächsten Kapitel.

Begründung Der rote Ausgangstest soll die erste notwendige Struktur sichtbar treiben.