Refactoring-Taxonomie: drei genau unterschiedene Aenderungsarten

"Migration" wird in diesem Projekt oft als Sammelbegriff verwendet, verdeckt dabei aber drei fachlich sehr unterschiedliche Dinge. Diese Doku legt die drei Kategorien exakt fest und definiert eine feste, grep-bare Kennzeichnung im Code (Javadoc-Leitzeile), damit jede Codestelle eindeutig einer Kategorie zugeordnet ist - nicht nur informell in Prosa erklaert.

Die drei Kategorien

1. Migration (unveraendert)

Reine Fachlogik ohne EJB-/Spring-Bezug wird wortgleich in den neuen Stack uebernommen - keine Verhaltensaenderung, keine strukturelle Aenderung, nur ein neues Package/eine neue Traegerklasse. Beispiel: PolicyStatus (Statusuebergangsregeln), die Basissaetze und der Risikomultiplikator in PremiumCalculationService.

Code-Kennzeichnung: **Migration (unveraendert):** als erste Zeile des erklaerenden Javadoc-Absatzes, oder - wenn nichts zu erklaeren ist, weil wirklich nichts strukturell anders ist - ein kurzer Verweis auf die Legacy-Quelle ohne weiteren Kommentar.

2. Refactoring

Das fachliche Verhalten bleibt absichtlich identisch, aber die interne Struktur/das Programmiermodell aendert sich, weil der EJB-Container durch Spring ersetzt wird (Container- Automatik wird zu explizitem Anwendungscode, oder umgekehrt). Das ist die groesste Kategorie in diesem Migrationsprojekt. Beispiele:

• PolicyNotFoundException/UnderwritingRejectedException: checked Exception + @ApplicationException -> unchecked RuntimeException + @Transactional(noRollbackFor=...).
• PolicyJpaRepository: @Stateless-Bean mit injiziertem EntityManager -> Spring-Data- Interface (Singleton-Proxy, kein manuelles EntityManager-Handling).
• AuditAspect: zwei EJB-Interceptor-Bindungsarten (annotationsbasiert vs. ejb-jar.xml) -> ein einziger, globaler AOP-Pointcut-Ausdruck.
• PolicyController: zwei getrennte Interfaces (PolicyManagementLocal/Remote) -> ein REST-Controller.
• PremiumCalculationService: UserTransaction-Boilerplate (BMT) -> TransactionTemplate (Spring-programmatische Transaktion).

Code-Kennzeichnung: **Refactoring:** als erste Zeile des erklaerenden Javadoc-Absatzes, gefolgt von einer kurzen Vorher/Nachher-Gegenueberstellung.

3. Bugfix

Ein tatsaechlicher Verhaltensfehler im Legacy-Original wird beim Neubau entdeckt und korrigiert - keine Stiluebersetzung, sondern eine echte Korrektur eines vorher falschen Ergebnisses. Bisher genau ein Fall: PolicyManagementService.generatePolicyNumber (Legacy verwendet System.nanoTime() direkt, das die 20-Zeichen-Spalte POLICY_NUMBER praktisch immer sprengt - nur durch Mockito-gemockte Repositories im Legacy-Unit-Test nie aufgefallen).

Code-Kennzeichnung: **Bugfix:** als erste Zeile, mit Erklaerung, warum der Legacy-Test das nicht gefunden hat (fehlende Testabdeckung ist Teil der Ursache, nicht nur der Bug selbst).

Warum diese Unterscheidung wichtig ist

• Migration (unveraendert) darf beim Review 1:1 mit dem Legacy-Original verglichen werden - jede Abweichung waere ein Fehler.
• Refactoring darf beim Review auf Verhaltensgleichheit, nicht auf Code-Aehnlichkeit geprueft werden - die Frage ist "verhaelt es sich gleich", nicht "sieht es gleich aus".
• Bugfix muss im Legacy-Modul bewusst NICHT nachgezogen werden (der Legacy-Reactor bleibt als "Vorher"-Referenz unveraendert, siehe 00-uebersicht.md) - stattdessen wird der Fund hier dokumentiert, damit er nicht als neuer Fehler missverstanden wird.

Fundstellen (grep-bar)

grep -rn "\*\*Migration (unveraendert):\*\*" novaris-modern-parent/
grep -rn "\*\*Refactoring:\*\*" novaris-modern-parent/
grep -rn "\*\*Bugfix:\*\*" novaris-modern-parent/