# ADR001-WP2-005 -- Relational Repositories and Data Mapper

## LA Review Summary

**Status:** Changes required (konzeptionelle Präzisierung)\
**Reviewer:** LA

------------------------------------------------------------------------

# Executive Summary

Das Grundprinzip des ADR ist überzeugend:

-   fachliche Repositorys statt Repositorys pro Tabelle,
-   kleine spezialisierte Data Mapper,
-   klare Trennung zwischen Application und Infrastructure.

Beim Abgleich mit dem aktuellen Projektstand ergeben sich jedoch zwei
konzeptionelle Punkte, die vor der Implementierung geklärt werden
sollten.

Diese betreffen nicht die Qualität des Entwurfs, sondern seine
Konsistenz mit ADR001 und dem bereits implementierten Domainmodell.

------------------------------------------------------------------------

# 1. Aggregate Boundary

## Feststellung

ADR001 arbeitet derzeit mit zwei fachlichen Aggregate-Repositories:

-   SourceValueRepository
-   ReconciliationResultRepository

WP2-005 beschreibt dagegen faktisch ein gemeinsames Repository:

``` text
RelationalReconciliationRepository
```

Dieses würde beide Aggregate zu einer neuen Aggregate Boundary
zusammenführen.

## Bewertung

Diese Änderung ist architektonisch möglich, überschreibt jedoch
stillschweigend eine bereits etablierte Entscheidung.

## Empfehlung

Die bestehende Trennung sollte beibehalten werden:

``` text
RelationalSourceValueRepository
RelationalReconciliationResultRepository
```

Die gemeinsame transaktionale Koordination erfolgt später in WP2-007.

------------------------------------------------------------------------

# 2. Technische Primärschlüssel

## Feststellung

Der ADR fordert:

> Technische Primärschlüssel bleiben vollständig innerhalb der
> Infrastructure Layer.

Der aktuelle Projektstand verwendet jedoch bereits nullable technische
IDs innerhalb der Domain Objects.

## Bewertung

Die Aussage des ADR ist deshalb zu absolut formuliert.

## Empfehlung

Präzisierung:

> Technische Primärschlüssel werden ausschließlich von der Persistence
> Layer erzeugt und zugeordnet. SQL- und Fremdschlüsselkoordination
> verbleiben vollständig innerhalb der Infrastructure Layer.

------------------------------------------------------------------------

# 3. Repository Contracts

Der ADR spricht von bestehenden oder präzisierten Contracts.

Im aktuellen Projektstand sollten diese Repository Contracts im Rahmen
von WP2-005 explizit eingeführt werden.

Empfohlene Struktur:

``` text
Application/
└── Persistence/
    ├── SourceValueRepository
    └── ReconciliationResultRepository
```

------------------------------------------------------------------------

# 4. Candidate-Zuordnung

Die Zuordnung

``` text
selectedCandidateUri
```

nach

``` text
selected_candidate_item_id
```

ist sehr sauber beschrieben.

Besonders positiv:

-   keine erneute Datenbanksuche,
-   keine Speicherung mit NULL,
-   eindeutiger Fehler bei fehlender Zuordnung.

------------------------------------------------------------------------

# 5. Data Mapper

Die Formulierung

> klein und spezialisiert bedeutet nicht zwingend ein Mapper pro Tabelle

ist aus Architektursicht ausdrücklich zu begrüßen.

Sie verhindert sowohl monolithische Mapper als auch künstliche
Überfragmentierung.

------------------------------------------------------------------------

# 6. Insert-Strategie

Die Entscheidung für eine reine Insert-Semantik ist richtig.

Idempotenz, Merge oder Upsert sollten erst nach einer fachlichen
Entscheidung eingeführt werden.

------------------------------------------------------------------------

# Antworten auf die Review-Fragen

1.  Aggregate Repository statt Repository pro Tabelle?\
    **Ja.** Allerdings weiterhin zwei fachliche Aggregate-Repositories.

2.  RelationalReconciliationRepository korrekt?\
    **Nur dann**, wenn bewusst eine neue Aggregate Boundary eingeführt
    wird.

3.  Mehrere spezialisierte Mapper?\
    **Ja.**

4.  Technische IDs ausschließlich Infrastructure?\
    **Präzisieren.** SQL-Koordination bleibt in Infrastructure,
    bestehende Domain-IDs bleiben zulässig.

5.  Candidate-URI-Mapping?\
    **Ja.**

6.  Abgrenzung WP2-006 / WP2-007?\
    **Ja.**

7.  Nur Insert?\
    **Ja.**

8.  Teststrategie ausreichend?\
    **Ja**, nach Anpassung der Assertions bezüglich Domain-IDs.

9.  Implementierbar?\
    **Ja**, nach den beiden konzeptionellen Präzisierungen.

------------------------------------------------------------------------

# Fazit

WP2-005 besitzt eine sehr starke Grundarchitektur.

Vor der Umsetzung sollten lediglich

1.  die Aggregate Boundary und
2.  die Beschreibung der technischen Identitäten

mit ADR001 und dem aktuellen Projektstand harmonisiert werden.

Danach kann das Workpackage aus Sicht der Architektur umgesetzt werden.