73 lines
3.4 KiB
Markdown
73 lines
3.4 KiB
Markdown
# 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.AsvValidatorApplication` → **vorerst** nach `adapter.in.cli`, wird in AP06 refaktoriert
|
||
- `de.gecheckt.asv.cli.ValidationResultPrinter` → `adapter.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`.
|