# DM002_PERSISTENCE_MODEL_v0.5_DRAFT_ED_LA_REVIEW_SUMMARY

**Review Role:** LA (Lead Architect)  
**Review Status:** Accepted in principle – minor revision recommended

## Gesamtbewertung

DM002 v0.5 stellt gegenüber den früheren Versionen einen deutlichen Qualitätssprung dar. Das Dokument beschreibt inzwischen ein logisches Persistenzmodell und positioniert sich sauber zwischen DM001 und der Implementierung.

Aus LA-Sicht bestehen keine grundlegenden Architekturprobleme. Die empfohlenen Änderungen dienen überwiegend der weiteren Schärfung der Verantwortlichkeiten und der langfristigen Wartbarkeit.

---

# Zentrale Empfehlung für DM002 v0.6

## Konsequente Reduzierung auf logische Persistenz

Die wichtigste Weiterentwicklung für die nächste Version besteht darin, DM002 vollständig auf die **logische Persistenz** zu fokussieren.

DM002 sollte beschreiben,

- **welcher fachliche Zustand dauerhaft gespeichert wird**,

nicht jedoch,

- **wie dieser in einer konkreten Datenbank umgesetzt wird.**

Damit ergibt sich folgende saubere Schichtung:

```text
ADR001
Grundsatzentscheidungen

↓

ADR002
Source Architecture

↓

DM001
Welche fachlichen Aggregate existieren?

↓

DM002
Welcher fachliche Zustand wird dauerhaft gespeichert?

↓

WP2
Wie wird dieser Zustand technisch persistiert?

↓

SQL / Migrationen / Repositorys / Mapper
```

### Konsequenzen

Für DM002 wird empfohlen:

- SQL-basierte Tabellenbezeichnungen (`source_delivery`, `candidate_item`, …) entfernen.
- SQL-Spaltennamen (`source_system_id`, `received_at`, `candidate_provider_uri`, …) entfernen.
- Stattdessen fachliche persistente Eigenschaften beschreiben.

Beispiel:

statt

| Column | Meaning |
|---|---|
| source_system_id | FK |

besser

| Persisted Property | Meaning |
|---|---|
| SourceSystem Reference | Referenz auf genau ein SourceSystem |

Die konkreten SQL-Namen werden Bestandteil von WP2.

Dadurch bleibt DM002 unabhängig von MySQL, PostgreSQL oder anderen Persistenztechnologien.

---

# Weitere Empfehlungen

## 1. Dokumenthierarchie

Die Trennung

ADR → DM001 → DM002 → WP2

ist ausgezeichnet und sollte beibehalten werden.

---

## 2. Persistenzprinzipien

Die Kapitel

- Aggregate First
- Stable Identity
- Persistence Ignorance
- Separation of Concerns
- Immutable Provenance
- Evolutionary Persistence

bilden eine sehr starke Grundlage und sollten unverändert bleiben.

---

## 3. Immutable Provenance

Die Entscheidung,

> Eine Änderung der Provenienz erzeugt fachlich einen neuen Eingangswert.

ist architektonisch überzeugend und konsequent.

---

## 4. candidateProviderUri

Die Umbenennung gegenüber `candidateSourceSystemUri` ist eine deutliche Verbesserung.

Sie trennt nun sauber:

- SourceSystem
- targetVocabularyUri
- candidateProviderUri

---

## 5. CandidateItem

Empfohlene Ergänzung:

> CandidateItems besitzen außerhalb ihres ReconciliationResult keine eigenständige fachliche Identität.

---

## 6. DeliveryChannel

Die Entscheidung als Value Object wird unterstützt.

Ergänzend sollte DM002 klarstellen:

> DM002 trifft bewusst keine Aussage, ob dieses Value Object als einzelne Spalte, strukturierter Datentyp oder spätere Referenztabelle persistiert wird.

---

## 7. Referential Integrity

Empfohlene Ergänzung:

> Die dargestellte Persistierreihenfolge ergibt sich aus den fachlichen Abhängigkeiten der Aggregate. Sie beschreibt keine konkrete technische Repository- oder SQL-Reihenfolge.

---

## 8. Lifecycle

Empfohlene Ergänzung:

> Neue Reconciliation-Läufe erweitern den fachlichen Zustand, ohne die Provenienz eines bereits persistierten SourceValue zu verändern.

---

# Gesamtbewertung

| Bereich | Bewertung |
|---|---|
| Trennung DM001 / DM002 | Ausgezeichnet |
| Persistenzprinzipien | Sehr gut |
| Aggregate Mapping | Sehr gut |
| Provenance-Modell | Sehr gut |
| DeliveryChannel | Überzeugend |
| candidateProviderUri | Deutliche Verbesserung |
| Integritätskapitel | Sehr gut |
| Dokumentstruktur | Sehr gut |

---

# Schlussurteil

DM002 v0.5 ist aus LA-Sicht fachlich konsistent und architektonisch tragfähig.

Für DM002 v0.6 wird empfohlen, den nächsten konsequenten Schritt zu gehen und das Dokument vollständig auf die **logische Persistenz** zu fokussieren. Alle physischen SQL-Artefakte (Tabellennamen, Spaltennamen, Datenbankdetails) sollten nach WP2 verlagert werden.

Dadurch entsteht eine außergewöhnlich klare Trennung zwischen fachlichem Modell, logischem Persistenzmodell und physischer Implementierung.