Files
asv-format-validator/docs/arbeitspakete/m1/AP03-hexagonale-paketstruktur.md

3.4 KiB
Raw Blame History

AP03 Hexagonale Paketstruktur anlegen und Ist-Code migrieren

Ziel

Die Soll-Paketstruktur aus technik-und-architektur.md im Projekt anlegen und den bestehenden Code evolutionär in die neuen Pakete verschieben, ohne Funktionalität zu verlieren. Alle bestehenden Tests müssen weiterhin grün laufen.

Voraussetzungen

  • AP01 (Ist-Stand bekannt)
  • AP02 (Build ist grün)

Scope IN

  • Anlage der Soll-Pakete:
    de.gecheckt.asv.domain
    de.gecheckt.asv.application
    de.gecheckt.asv.adapter.in.cli
    de.gecheckt.asv.adapter.out.filesystem
    de.gecheckt.asv.adapter.out.parsing
    de.gecheckt.asv.adapter.out.reporting
    de.gecheckt.asv.adapter.out.logging
    de.gecheckt.asv.bootstrap
    
    (Paket adapter.out.crypto kommt erst in M8.)
  • Migration des bestehenden Codes nach folgender Zuordnung:
    • de.gecheckt.asv.cli.AsvValidatorApplicationvorerst nach adapter.in.cli, wird in AP06 refaktoriert
    • de.gecheckt.asv.cli.ValidationResultPrinteradapter.out.reporting (technische Berichtsausgabe ist Adapter-Zuständigkeit)
    • de.gecheckt.asv.domain.model.*domain (Paket .model darf bleiben als Unterpaket von domain)
    • de.gecheckt.asv.parser.*adapter.out.parsing
    • de.gecheckt.asv.validation.* (inkl. field/, structure/, model/) → vorerst unter application belassen, bis AP09 klärt, was davon wirklich nach application gehört und was ggf. in einem eigenen Unterpaket „eingefroren" bleibt
  • alle package-Deklarationen und import-Statements anpassen
  • alle Tests entsprechend mit verschieben
  • Build und Tests bleiben grün
  • einfaches Package-Diagramm als Markdown-Tabelle im Abschlussbericht

Scope OUT

  • inhaltliche Umstellung der Klassen (Exit-Codes, Zeichensatz, Befundmodell — das kommt in späteren APs)
  • Einführung neuer Klassen
  • Löschen von Klassen
  • Refactoring von Methoden

Schritte

  1. Branch m1/ap03-hexagonale-pakete
  2. Leerverzeichnisse für die Soll-Pakete anlegen (notfalls .gitkeep, wird später entfernt)
  3. Klassen paketweise verschieben (IDE-Refactoring „Move Class" hilft hier enorm)
  4. Nach jeder Paket-Migration: mvn clean compile laufen lassen, muss grün bleiben
  5. Nach allen Migrationen: mvn clean verify — muss grün sein
  6. Kurze Paket-Beschreibung pro Paket in einem package-info.java hinzufügen (deutsche JavaDoc, ein bis zwei Sätze)
  7. Commit M1-AP03: Hexagonale Paketstruktur angelegt, Ist-Code migriert
  8. Abschlussbericht schreiben

Abnahmekriterien

  • alle oben genannten Soll-Pakete existieren als Java-Packages
  • kein Code ist verloren gegangen: git log --stat zeigt nur Verschiebungen und Import-Anpassungen, keine Löschungen
  • mvn clean verify ist grün
  • jede neue Paket-Wurzel hat ein package-info.java mit deutscher Kurzbeschreibung
  • Abschlussbericht enthält eine Vorher-Nachher-Tabelle jeder migrierten Klasse
  • keine neuen Features

Rest-Risiken und offene Punkte

  • Die Zuordnung der Validation-Klassen nach application ist provisorisch. AP09 entscheidet endgültig, was davon in M1 aktiv bleibt und was eingefroren wird.
  • AsvValidatorApplication bleibt vorerst im CLI-Adapter, wird aber in AP06 zerlegt (Bootstrap + dünner CLI-Adapter).
  • Die Tests-Struktur sollte die neue Paketstruktur spiegeln; falls das mit IDE-Move automatisch passiert: gut. Falls nicht: manuell nachziehen.

Bericht

docs/arbeitspakete/m1/berichte/AP03-bericht.md nach templates/ap-bericht.md.