Diese Referenz beschreibt nicht zwei Legacy-Systeme, sondern eine einzige Ausgangsbasis und die Sicherheitsmechanismen für eine schrittweise Ablösung.
Die Legacy-Anwendung modelliert sechs fachlich unterschiedliche, aber absichtlich schlecht getrennte Abläufe. Sie mischt Validierung, Preis- und Steuerberechnung, Datenbankzugriffe, Remote Calls, JMS, Audit und Event-Erzeugung innerhalb großer EJB-Transaktionen.
| Klasse | Fachliche Verantwortung | Typische Altlast |
|---|---|---|
| OrderProcessingMonsterBean | Order Intake bis Shipment | Remote Calls und viele Tabellen in einer Transaktion |
| BillingRunMonsterBean | Invoice, Collection, Dunning, Ledger | Batch und Online-Logik vermischt |
| CustomerContractMonsterBean | Customer Master und Contract Lifecycle | Stringly Typed Maps und Replace-Updates |
| InventoryReplenishmentMonsterBean | Reorder, Budget und Transport | Bestell- und Lagerlogik gekoppelt |
| ReturnsAndRefundMonsterBean | Return, Restocking, Refund | Payment, Stock und Shipment gemeinsam |
| EndOfDaySettlementMonsterBean | Reconciliation und Day Close | Globale Locks und erzwungener Abschluss |
DAO-SQL, JPA-Tabellennamen und Schema verwenden dieselben Namen: CUSTOMERS, ORDERS, ORDER_LINES, AUDIT_LOG, OUTBOX_EVENT und BATCH_CONTROL. Der reservierte Tabellenname ORDER wurde entfernt.
Golden-Master-Snapshots erfassen stabile Business-Ausgaben. H2-Integrationstests prüfen das reale Schema und alle JDBC-DAO-Namen. Unit Tests decken Happy Paths, Grenzfälle und Provider-/Datenfehler ab. Erst danach werden ACL, Strangler und Parallel Run eingesetzt.
Der moderne Pfad speichert Order und Outbox Event in einer Transaktion. Ein Publisher claimt fällige Zeilen per FOR UPDATE SKIP LOCKED, veröffentlicht mit Kafka, markiert erfolgreiche Events als SENT und plant Fehler als RETRY oder endgültig FAILED.
@Transactional
public Result place(Command command) {
orders.save(order);
outbox.save(event); // Transactional Outbox Pattern
}