# DM002 — Persistence Model

**Version:** 0.5 DRAFT ED  
**Status:** Draft  
**Scope:** Relational Persistence Model

---

# Related Documents

### Architecture Decision Records

- ADR001 — Domain Integration
- ADR002 — Source Delivery Model

### Domain Models

- DM001 — Domain Model

### Methodology

- ME001 — Interpretation Properties and Vocabulary Matching Patterns
- ME002 — Interpretation Driven Reconciliation

---

# 1. Purpose

DM002 beschreibt das relationale Persistenzmodell von Reconcilix.

Während DM001 die fachlichen Aggregate, Beziehungen und fachlichen Invarianten definiert, beschreibt DM002 deren dauerhafte Speicherung in einer relationalen Datenbank.

Der Schwerpunkt dieses Dokuments liegt auf der Abbildung fachlicher Aggregate auf persistente Datenstrukturen.

DM002 definiert insbesondere

- persistente Aggregate,
- Tabellenstrukturen,
- Identitäten,
- Beziehungen,
- referenzielle Integrität,
- Persistenzprinzipien
- sowie die Zuordnung fachlicher Aggregate zu relationalen Tabellen.

DM002 beschreibt ausdrücklich nicht

- fachliche Matchingregeln,
- Interpretationsverfahren,
- Candidate Discovery,
- Reconciliation-Prozesse,
- Benutzeroberflächen,
- technische Implementierungsdetails.

Diese Aspekte werden in

- DM001,
- ME001,
- ME002
- sowie den Work Packages

beschrieben.

---

# 2. Scope

Dieses Dokument beschreibt ausschließlich die logische Persistenzarchitektur.

Es definiert

- welche fachlichen Aggregate persistent gespeichert werden,
- wie Aggregate relational repräsentiert werden,
- welche Beziehungen dauerhaft gespeichert werden,
- welche Integritätsregeln dauerhaft gelten.

Nicht Bestandteil dieses Dokuments sind

- konkrete SQL-Skripte,
- Datenbankmigrationen,
- Repository-Implementierungen,
- ORM-Konfigurationen,
- Datenbankoptimierungen,
- Laufzeitverhalten.

Diese Aspekte gehören zur Implementierung und werden in den jeweiligen Work Packages beschrieben.

---

# 3. Architectural Position

Die Reconcilix-Architektur trennt konsequent zwischen

- fachlichem Modell,
- Persistenzmodell
- und Implementierung.

```text
Architecture Decisions
          │
          ▼
      Domain Model
          │
          ▼
   Persistence Model
          │
          ▼
Implementation
```

Diese Trennung verfolgt zwei Ziele.

Erstens bleibt das fachliche Modell unabhängig von der gewählten Persistenztechnologie.

Zweitens kann die Persistenz unabhängig von konkreten Frameworks oder Implementierungsdetails weiterentwickelt werden.

DM002 bildet damit die stabile Schnittstelle zwischen fachlicher Modellierung und technischer Umsetzung.

---

# 4. Persistence Principles

Die Persistenzarchitektur von Reconcilix orientiert sich konsequent am Domain Model.

Die folgenden Prinzipien gelten dokumentübergreifend.

---

## 4.1 Aggregate First

Persistiert werden ausschließlich fachliche Aggregate.

Tabellen entstehen nicht durch rein relationale Normalisierung, sondern durch fachliche Verantwortlichkeiten.

Dadurch bleibt die Persistenzstruktur langfristig stabil.

---

## 4.2 Stable Identity

Jedes Aggregate besitzt genau eine persistente Identität.

Persistente Identitäten bleiben über den gesamten Lebenszyklus eines Aggregates unverändert.

Beziehungen zwischen Aggregaten werden ausschließlich über diese Identitäten hergestellt.

---

## 4.3 Persistence Ignorance

Die Domain kennt keine Persistenz.

Domain Objects enthalten insbesondere keine

- SQL-Abhängigkeiten,
- Datenbankzugriffe,
- Persistenzlogik,
- Implementierungsdetails.

Die Persistenz bildet ausschließlich den fachlichen Zustand dauerhaft ab.

---

## 4.4 Separation of Concerns

Persistenz ersetzt keine fachliche Logik.

Die Datenbank gewährleistet

- Identitäten,
- Referenzen,
- technische Integrität.

Fachliche Invarianten bleiben Aufgabe der Domain beziehungsweise der koordinierenden Application Services.

---

## 4.5 Immutable Provenance

Die Herkunft eines SourceValue ist Bestandteil seiner fachlichen Identität.

Nach erfolgreicher Persistierung dürfen die Beziehungen

```text
SourceSystem
↓

SourceDelivery
↓

SourceValue
```

nicht mehr verändert werden.

Eine Änderung der Provenienz erzeugt fachlich einen neuen Eingangswert.

---

## 4.6 Evolutionary Persistence

Die Persistenzarchitektur wird bewusst offen für zukünftige Erweiterungen gehalten.

Neue Aggregate sollen ergänzt werden können,

ohne bestehende Aggregate grundlegend verändern zu müssen.

Dieses Prinzip unterstützt insbesondere zukünftige Erweiterungen wie

- zusätzliche Knowledge Sources,
- neue Candidate Provider,
- alternative Discovery-Verfahren,
- weitere Persistenztechnologien.

---

# 5. Aggregate Overview

Die Persistenz folgt unmittelbar den Aggregaten des Domain Models.

| Domain Aggregate | Primary Table |
|------------------|---------------|
| SourceSystem | source_system |
| SourceDelivery | source_delivery |
| SourceValue | source_value |
| InterpretationGraph | interpretation_graph |
| InterpretationNode | interpretation_node |
| ReconciliationResult | reconciliation_result |
| CandidateItem | candidate_item |
| MatchDecision | match_decision |

Zusätzliche Tabellen können zur Unterstützung der Persistenz entstehen.

Diese stellen jedoch keine eigenen fachlichen Aggregate dar.

---

# 6. Aggregate Dependencies

Die Beziehungen der Aggregate ergeben sich unmittelbar aus DM001.

```text
SourceSystem
        │
        ▼
SourceDelivery
        │
        ▼
SourceValue
        │
        ▼
InterpretationGraph
        │
        ▼
InterpretationNode
        │
        ▼
ReconciliationResult
       ├──────────────┐
       ▼              ▼
CandidateItem   MatchDecision
```

Dieses Diagramm beschreibt ausschließlich fachliche Persistenzabhängigkeiten.

Es trifft keine Aussage über

- Transaktionen,
- Repositorys,
- Implementierungsdetails.

Diese werden in späteren Kapiteln beschrieben.

---

# 7. Source Provenance

Mit ADR002 wurde die Provenance-Struktur grundlegend erweitert.

Die Herkunft eines Eingangswertes wird nun nicht mehr unmittelbar am SourceValue gespeichert, sondern über die Aggregate

- SourceSystem
- SourceDelivery

modelliert.

Dadurch können

- mehrere Lieferungen desselben Ursprungssystems,
- unterschiedliche Importkanäle,
- verschiedene Datenlieferungen

dauerhaft nachvollzogen werden.

Die Provenance-Struktur bildet den Einstieg jedes Reconciliation-Prozesses.

---

# 8. Status nach Teil 1

Teil 1 definiert

- die Rolle des Persistenzmodells innerhalb der Gesamtarchitektur,
- die grundlegenden Persistenzprinzipien,
- die persistenten Aggregate,
- sowie deren fachliche Beziehungen.

Die folgenden Kapitel beschreiben die relationale Modellierung der einzelnen Aggregate und ihrer Beziehungen.

# 9. Aggregate: SourceSystem

## Responsibility

SourceSystem repräsentiert das fachliche Ursprungssystem einer oder mehrerer Datenlieferungen.

Es beschreibt die Herkunft einer Lieferung unabhängig von deren technischem Transport oder Importprozess.

Typische Beispiele sind

- digiCULT.web
- MuseumPlus
- Adlib
- CollectiveAccess

Ein SourceSystem beschreibt somit eine fachliche Quelle und keine konkrete Datenlieferung.

---

## Persistence

Primary Table

```text
source_system
```

Empfohlene Kernattribute

| Column | Meaning |
|---------|----------|
| id | Primary Key |
| name | fachlicher Name |
| uri | optionale stabile URI |

Weitere Attribute können projektspezifisch ergänzt werden.

---

## Constraints

Minimal gelten

- Primary Key
- Name obligatorisch

Eine URI kann optional eindeutig geführt werden.

---

# 10. Aggregate: SourceDelivery

## Responsibility

SourceDelivery beschreibt eine konkrete Lieferung eines SourceSystems.

Mehrere Lieferungen desselben Ursprungssystems werden dadurch dauerhaft voneinander unterschieden.

Eine SourceDelivery besitzt insbesondere

- genau ein SourceSystem,
- einen Lieferzeitpunkt,
- optionale externe Kennungen,
- einen optionalen DeliveryChannel.

---

## Persistence

Primary Table

```text
source_delivery
```

Empfohlene Kernattribute

| Column | Meaning |
|---------|----------|
| id | Primary Key |
| source_system_id | FK |
| delivery_channel | Value Object |
| external_delivery_id | optionale Kennung |
| received_at | Zeitpunkt |

---

## DeliveryChannel

DeliveryChannel bleibt Bestandteil des SourceDelivery Aggregates.

Er wird nicht als eigenständiges Aggregate modelliert.

Die konkrete Persistierung des Value Objects ist eine Implementierungsentscheidung.

DM002 fordert lediglich die dauerhafte Speicherung des fachlichen Zustandes.

---

## Relationship

```text
SourceSystem

1

↓

n

SourceDelivery
```

Eine Lieferung gehört immer genau zu einem SourceSystem.

---

# 11. Aggregate: SourceValue

## Responsibility

SourceValue repräsentiert den unveränderten fachlichen Eingangswert.

Er bildet den Ausgangspunkt sämtlicher Interpretations- und Reconciliation-Prozesse.

Mit ADR002 gehört jeder SourceValue genau zu einer SourceDelivery.

---

## Persistence

Primary Table

```text
source_value
```

Neue verpflichtende Beziehung

```text
source_delivery_id
```

Dadurch wird die Provenance dauerhaft nachvollziehbar.

---

## Relationship

```text
SourceDelivery

1

↓

n

SourceValue
```

Ein SourceValue existiert niemals ohne zugehörige SourceDelivery.

---

# 12. Aggregate: InterpretationGraph

## Responsibility

InterpretationGraph beschreibt eine konkrete fachliche Interpretation eines SourceValue.

Er bildet die Wurzel sämtlicher Interpretationsknoten.

Die Persistenz ermöglicht insbesondere

- alternative Interpretationen,
- zukünftige Versionierungen,
- unterschiedliche Auswertungsstrategien.

---

## Persistence

Primary Table

```text
interpretation_graph
```

Empfohlene Kernattribute

| Column | Meaning |
|---------|----------|
| id | Primary Key |
| source_value_id | FK |
| status | Bearbeitungsstatus |
| version | Version |
| created_at | Zeitstempel |

Weitere Attribute ergeben sich aus der fachlichen Weiterentwicklung.

---

## Relationship

```text
SourceValue

1

↓

n

InterpretationGraph
```

---

# 13. Aggregate: InterpretationNode

## Responsibility

InterpretationNode beschreibt einen einzelnen Interpretationsschritt innerhalb eines InterpretationGraph.

Nodes bilden gemeinsam den vollständigen Interpretationsbaum.

---

## Persistence

Primary Table

```text
interpretation_node
```

Empfohlene Kernattribute

| Column | Meaning |
|---------|----------|
| id | Primary Key |
| interpretation_graph_id | FK |
| parent_node_id | optionale FK |
| value | interpretierter Wert |
| level | Ebene |
| status | Bearbeitungsstatus |
| created_at | Zeitstempel |

Die genaue interne Struktur bleibt unabhängig vom Persistenzmodell erweiterbar.

---

## Relationship

```text
InterpretationGraph

1

↓

n

InterpretationNode
```

InterpretationNodes können zusätzlich rekursive Parent-Child-Beziehungen besitzen.

---

# 14. Controlled Properties

InterpretationNodes können beliebig viele Interpretation Properties besitzen.

Diese werden unabhängig vom eigentlichen Aggregate gespeichert.

Die Properties werden ausschließlich über ihre stabile URI referenziert.

DM002 trifft bewusst keine Aussage darüber,

- wie Interpretation Properties verwaltet werden,
- wo deren Definition gespeichert wird,
- wie URIs aufgelöst werden.

Diese Aspekte gehören zum Methodikmodell (ME001).

---

# 15. Aggregate: ReconciliationResult

## Responsibility

ReconciliationResult beschreibt das Ergebnis eines fachlichen Reconciliation-Versuchs.

Ein InterpretationNode kann mehrere ReconciliationResults besitzen.

Beispielsweise

- unterschiedliche Zielvokabulare,
- verschiedene Discovery-Verfahren,
- spätere Wiederholungen.

---

## Persistence

Primary Table

```text
reconciliation_result
```

Empfohlene Kernattribute

| Column | Meaning |
|---------|----------|
| id | Primary Key |
| interpretation_node_id | FK |
| target_vocabulary_uri | URI |
| created_at | Zeitstempel |

Weitere Bewertungsattribute können projektspezifisch ergänzt werden.

---

## Relationship

```text
InterpretationNode

1

↓

n

ReconciliationResult
```

---

# 16. Vocabulary Matching Pattern

Ein ReconciliationResult kann optional einem Vocabulary Matching Pattern zugeordnet werden.

Das Pattern beschreibt die fachliche Qualität der gefundenen Übereinstimmung.

Die Definition der Patterns erfolgt ausschließlich in ME001.

DM002 beschreibt lediglich deren Persistierung.

---

# 17. Aggregate: CandidateItem

## Responsibility

CandidateItem beschreibt einen während eines Reconciliation-Versuchs gefundenen Kandidaten.

Ein CandidateItem existiert ausschließlich innerhalb eines ReconciliationResult.

---

## Persistence

Primary Table

```text
candidate_item
```

Empfohlene Kernattribute

| Column | Meaning |
|---------|----------|
| id | Primary Key |
| reconciliation_result_id | FK |
| uri | Candidate URI |
| display_label | Anzeige |
| candidate_provider_uri | Provider |
| score | Bewertung |

Weitere Attribute können ergänzt werden, ohne die Aggregate-Struktur zu verändern.

---

## Relationship

```text
ReconciliationResult

1

↓

n

CandidateItem
```

---

# 18. Aggregate: MatchDecision

## Responsibility

MatchDecision beschreibt die fachliche Entscheidung über einen Reconciliation-Versuch.

Sie dokumentiert

- automatische Entscheidungen,
- manuelle Entscheidungen,
- spätere Korrekturen.

---

## Persistence

Primary Table

```text
match_decision
```

Empfohlene Kernattribute

| Column | Meaning |
|---------|----------|
| id | Primary Key |
| reconciliation_result_id | FK |
| decision | Entscheidung |
| decided_at | Zeitpunkt |
| decided_by | Bearbeiter |

Die Referenz auf einen ausgewählten Candidate bleibt bewusst Bestandteil der fachlichen Modellierung.

DM002 legt hierfür keine konkrete relationale Umsetzung fest.

---

## Relationship

```text
ReconciliationResult

1

↓

n

MatchDecision
```

---

# 19. Status nach Teil 2

Mit Teil 2 sind sämtliche fachlichen Aggregate des Persistenzmodells beschrieben.

Für jedes Aggregate wurden

- fachliche Verantwortung,
- primäre Persistenzstruktur,
- grundlegende Beziehungen

definiert.

Die folgenden Kapitel beschreiben

- Integritätsregeln,
- Persistenzprinzipien,
- Transaktionsgrenzen,
- sowie zukünftige Erweiterungsmöglichkeiten.

# 20. Persistence Integrity

Persistenz bedeutet mehr als die dauerhafte Speicherung einzelner Datensätze.

Das Persistenzmodell muss sicherstellen, dass dauerhaft nur fachlich konsistente Zustände gespeichert werden können.

Dabei unterscheidet Reconcilix bewusst zwischen

- technischer Integrität,
- struktureller Integrität,
- fachlicher Integrität.

---

## 20.1 Technical Integrity

Die relationale Datenbank gewährleistet insbesondere

- eindeutige Identitäten,
- gültige Referenzen,
- Datentypen,
- obligatorische Attribute.

Diese Regeln werden dauerhaft durch die Persistenzschicht abgesichert.

---

## 20.2 Structural Integrity

Die Beziehungen der Aggregate bleiben dauerhaft erhalten.

Beispielsweise gilt

```text
SourceSystem

↓

SourceDelivery

↓

SourceValue
```

sowie

```text
SourceValue

↓

InterpretationGraph

↓

InterpretationNode

↓

ReconciliationResult
```

Persistente Beziehungen dürfen niemals in einen inkonsistenten Zustand gelangen.

---

## 20.3 Domain Integrity

Nicht jede fachliche Invariante kann durch relationale Mittel garantiert werden.

Beispiele sind

- genau eine finale MatchDecision,
- vollständige SourceDeliveries,
- zulässige Vocabulary Matching Patterns,
- fachliche Konsistenz einer Interpretation.

Diese Regeln bleiben Bestandteil des Domain Models und werden durch die koordinierenden Application Services sichergestellt.

DM002 dokumentiert diese Regeln, implementiert sie jedoch nicht.

---

# 21. Aggregate Relationships

Die Persistenz übernimmt die Beziehungen des Domain Models unverändert.

| Parent Aggregate | Child Aggregate |
|------------------|-----------------|
| SourceSystem | SourceDelivery |
| SourceDelivery | SourceValue |
| SourceValue | InterpretationGraph |
| InterpretationGraph | InterpretationNode |
| InterpretationNode | ReconciliationResult |
| ReconciliationResult | CandidateItem |
| ReconciliationResult | MatchDecision |

Diese Beziehungen bilden die dauerhafte Struktur eines Reconciliation-Prozesses.

---

# 22. Persistent Identity

Alle Aggregate besitzen eine dauerhaft stabile Identität.

Persistente Identitäten

- ändern sich niemals,
- werden nicht wiederverwendet,
- dienen ausschließlich der eindeutigen Identifikation eines Aggregates.

Fachliche Änderungen verändern niemals die Identität eines bestehenden Aggregates.

Entsteht fachlich ein neues Objekt,

entsteht ebenfalls eine neue persistente Identität.

---

# 23. Referential Integrity

Persistente Beziehungen müssen dauerhaft konsistent bleiben.

Das Persistenzmodell verlangt insbesondere,

dass referenzierte Aggregate existieren,

bevor abhängige Aggregate dauerhaft gespeichert werden.

Hieraus ergibt sich die grundlegende Persistierreihenfolge

```text
SourceSystem

↓

SourceDelivery

↓

SourceValue

↓

InterpretationGraph

↓

InterpretationNode

↓

ReconciliationResult

↓

CandidateItem

↓

MatchDecision
```

Die konkrete technische Umsetzung bleibt Bestandteil der Implementierung.

---

# 24. Lifecycle

Die Lebenszyklen der Aggregate orientieren sich an ihrer fachlichen Verantwortung.

Dabei entstehen zwei unterschiedliche Lebenszyklusgruppen.

---

## 24.1 Provenance

```text
SourceSystem

↓

SourceDelivery

↓

SourceValue
```

Diese Aggregate beschreiben die Herkunft eines Eingangswertes.

Sie bleiben nach erfolgreicher Persistierung grundsätzlich unverändert.

---

## 24.2 Interpretation

```text
InterpretationGraph

↓

InterpretationNode

↓

ReconciliationResult

↓

CandidateItem

↓

MatchDecision
```

Diese Aggregate entstehen während des Reconciliation-Prozesses.

Sie können durch spätere Reconciliation-Läufe erweitert werden.

Die Provenance eines SourceValue bleibt hiervon unberührt.

---

# 25. Transaction Principles

DM002 definiert keine konkreten Transaktionen.

Es gelten jedoch folgende Grundprinzipien.

---

## Atomicity

Ein persistenter Zustand darf niemals teilweise entstehen.

Nach Abschluss einer Operation befindet sich das Persistenzmodell entweder

- vollständig im alten Zustand

oder

- vollständig im neuen Zustand.

Zwischenzustände dürfen dauerhaft nicht sichtbar werden.

---

## Consistency

Persistente Zustände müssen jederzeit die in DM001 definierten Aggregate-Beziehungen erfüllen.

---

## Isolation

Parallel ausgeführte Persistenzoperationen dürfen sich gegenseitig nicht in einen inkonsistenten Zustand bringen.

Die konkrete Transaktionssteuerung bleibt Bestandteil der Implementierung.

---

## Durability

Ein erfolgreich persistierter fachlicher Zustand bleibt dauerhaft erhalten.

---

# 26. Performance Principles

Performance ist kein primäres Entwurfsziel des Persistenzmodells.

Vorrang besitzen

- fachliche Verständlichkeit,
- Wartbarkeit,
- Erweiterbarkeit,
- Stabilität.

Performanceoptimierungen dürfen diese Prinzipien nicht verletzen.

Konkrete Indizes,

Datenbankoptimierungen

oder

physische Speicherstrategien

sind nicht Bestandteil von DM002.

---

# 27. Evolution Principles

Das Persistenzmodell soll zukünftige Erweiterungen ermöglichen,

ohne bestehende Aggregate grundlegend verändern zu müssen.

Insbesondere sollen ergänzt werden können

- weitere Candidate Provider,
- zusätzliche Knowledge Sources,
- neue Discovery-Verfahren,
- weitere Reconciliation-Strategien,
- alternative Persistenztechnologien.

Die Aggregate-Struktur bleibt dabei möglichst unverändert.

---

# 28. Status nach Teil 3

Mit Teil 3 sind

- Persistenzprinzipien,
- Integritätsregeln,
- Lebenszyklen,
- Beziehungen,
- Persistenzidentitäten

vollständig beschrieben.

Die abschließenden Kapitel behandeln

- zukünftige Erweiterungen,
- die Einordnung innerhalb der Gesamtarchitektur
- sowie die Dokumenthistorie.


# 29. Deferred Design

Die folgenden Themen wurden im Rahmen der Architektur bewusst zurückgestellt.

Sie sind erwartbare Weiterentwicklungen der Persistenzarchitektur, werden jedoch nicht Bestandteil der Version 0.5.

## 29.1 Additional Knowledge Sources

Zukünftige Versionen können zusätzliche Wissensquellen integrieren.

Beispiele sind

- Wikidata,
- GND,
- Iconclass,
- weitere kontrollierte Vokabulare.

Die bestehende Aggregatestruktur soll hierfür unverändert nutzbar bleiben.

---

## 29.2 Additional Discovery Strategies

Candidate Discovery ist bewusst unabhängig vom Persistenzmodell.

Neue Verfahren können ergänzt werden,

beispielsweise

- Embedding-basierte Verfahren,
- Vector Search,
- hybride Discovery,
- regelbasierte Verfahren,
- externe Reconciliation Services.

Die Persistenz speichert ausschließlich deren Ergebnisse.

---

## 29.3 Additional Candidate Providers

Ein ReconciliationResult kann zukünftig Kandidaten unterschiedlicher Provider enthalten.

Die Persistenzarchitektur unterstützt diese Erweiterung bereits durch die Speicherung des `candidate_provider_uri`.

Weitere Anpassungen am Domänenmodell sind hierfür voraussichtlich nicht erforderlich.

---

## 29.4 Versioning

Spätere Versionen können eine weitergehende Versionierung fachlicher Aggregate unterstützen.

Dies betrifft insbesondere

- InterpretationGraph,
- ReconciliationResult,
- MatchDecision.

Die konkrete Versionierungsstrategie bleibt einer späteren Architekturentscheidung vorbehalten.

---

## 29.5 Alternative Persistence Technologies

DM002 beschreibt ein logisches Persistenzmodell.

Die Architektur ist daher nicht auf relationale Datenbanken beschränkt.

Alternative Persistenztechnologien können zukünftig verwendet werden,

sofern sie die in diesem Dokument beschriebenen fachlichen Invarianten gewährleisten.

---

# 30. Design Rationale

Das Persistenzmodell verfolgt vier wesentliche Architekturziele.

## Fachliche Nachvollziehbarkeit

Die Persistenz folgt konsequent den Aggregaten des Domain Models.

Die Datenstruktur bleibt dadurch auch ohne Kenntnis der Implementierung verständlich.

---

## Klare Verantwortlichkeiten

Jedes Aggregate besitzt eine eindeutig abgegrenzte fachliche Verantwortung.

Persistenz ersetzt keine fachliche Logik.

Ebenso enthält das Domain Model keine Persistenzlogik.

---

## Langfristige Erweiterbarkeit

Neue Discovery-Verfahren,

weitere Wissensquellen

oder zusätzliche Matching-Strategien

können ergänzt werden,

ohne bestehende Aggregate grundlegend verändern zu müssen.

---

## Technologieunabhängigkeit

Die Architektur beschreibt fachliche Anforderungen an die Persistenz.

Sie schreibt keine konkrete Persistenztechnologie oder Implementierungsstrategie vor.

Dadurch bleibt Reconcilix langfristig anpassungsfähig.

---

# 31. Relationship to Other Documents

Die Architekturdokumente bauen schrittweise aufeinander auf.

```text
ADR001
        │
        ▼
ADR002
        │
        ▼
DM001
        │
        ▼
DM002
        │
        ▼
WP2
```

Dabei übernimmt jedes Dokument eine klar abgegrenzte Verantwortung.

| Document | Responsibility |
|----------|----------------|
| ADR001 | grundlegende Architekturentscheidungen |
| ADR002 | Provenance- und Source-Architektur |
| DM001 | fachliches Domänenmodell |
| DM002 | logisches Persistenzmodell |
| WP2 | technische Umsetzung der Persistenz |

Diese Trennung reduziert Kopplungen zwischen Architektur und Implementierung und erleichtert die langfristige Weiterentwicklung.

---

# 32. Change Summary

## Version 0.5

Gegenüber Version 0.4 wurde das Dokument grundlegend überarbeitet.

Wesentliche Änderungen sind:

- konsequente Trennung von Architektur und Implementierung,
- Entfernung technologieabhängiger Beschreibungen,
- stärkere Orientierung am Domain Model,
- Überarbeitung der Persistenzprinzipien,
- klarere Abgrenzung zu WP2,
- sprachliche Vereinheitlichung,
- Reduktion redundanter Inhalte.

Dadurch beschreibt DM002 nun ausschließlich die logische Persistenzarchitektur.

---

# 33. Conclusion

DM002 bildet die dauerhafte Persistenzschicht der Reconcilix-Architektur.

Es überführt die in DM001 beschriebenen fachlichen Aggregate in ein stabiles relationales Persistenzmodell,

ohne deren fachliche Verantwortung zu verändern.

Gemeinsam mit

- ADR001,
- ADR002
- und DM001

entsteht damit eine konsistente Architektur,

die fachliche Modellierung,

Persistenz

und technische Umsetzung klar voneinander trennt.

---

# Document History

| Version | Status | Description |
|----------|--------|-------------|
| 0.1 | Draft | Initial persistence model |
| 0.2 | Draft | Aggregate structure erweitert |
| 0.3 | Draft | Candidate Model überarbeitet |
| 0.4 | Draft | Persistenzmodell vollständig beschrieben |
| 0.5 | Draft ED | Architektur-Review, konsequente Trennung von Persistenz und Implementierung |