# DM002 — Persistence Model

**Version:** 0.5 ED-LA  
**Status:** Accepted for Implementation
**Scope:** Logical 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 logische Persistenzmodell von Reconcilix.

Während DM001 die fachlichen Aggregate, Beziehungen und Invarianten definiert, beschreibt DM002 den fachlichen Zustand, der dauerhaft erhalten werden muss.

Das Dokument beantwortet insbesondere folgende Fragen:

- Welche fachlichen Aggregate besitzen einen persistenten Zustand?
- Welche Informationen müssen dauerhaft gespeichert werden?
- Welche Beziehungen zwischen Aggregaten müssen dauerhaft erhalten bleiben?
- Welche Persistenzprinzipien gelten unabhängig von einer konkreten Persistenztechnologie?

DM002 beschreibt ausdrücklich nicht,

- wie Aggregate technisch gespeichert werden,
- welche Persistenztechnologie verwendet wird,
- wie Datenbankstrukturen aufgebaut sind,
- wie Repositorys implementiert werden,
- wie Migrationen durchgeführt werden.

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

---

# 2. Scope

Dieses Dokument beschreibt ausschließlich die logische Persistenzarchitektur.

Es definiert

- persistente Aggregate,
- den dauerhaft zu speichernden fachlichen Zustand,
- persistente Beziehungen,
- Persistenzidentitäten,
- logische Integritätsregeln.

Nicht Bestandteil dieses Dokuments sind insbesondere

- Datenbankschemata,
- Tabellenstrukturen,
- SQL-Artefakte,
- Spaltenbezeichnungen,
- Foreign Keys,
- Datenbankmigrationen,
- Repositorys,
- Mapper,
- Optimierungsstrategien.

DM002 bleibt dadurch unabhängig von einer konkreten Persistenztechnologie.

---

# 3. Architectural Position

Die Reconcilix-Architektur trennt konsequent zwischen fachlicher Modellierung, logischer Persistenz und technischer Implementierung.

```text
ADR001
Grundsatzentscheidungen

        │
        ▼

ADR002
Source Architecture

        │
        ▼

DM001
Domain Model

        │
        ▼

DM002
Logical Persistence Model

        │
        ▼

WP2
Persistence Implementation
```

Jede Ebene besitzt eine klar abgegrenzte Verantwortung.

DM002 bildet die stabile Schnittstelle zwischen fachlicher Modellierung und technischer Persistenz.

---

# 4. Persistence Principles

Die logische Persistenz folgt unmittelbar dem Domain Model.

Persistiert wird ausschließlich fachlicher Zustand.

Die konkrete technische Speicherung bleibt bewusst offen.

---

## 4.1 Aggregate First

Persistiert werden ausschließlich fachliche Aggregate.

Die Persistenz orientiert sich an den fachlichen Verantwortlichkeiten des Domain Models und nicht an technischen Optimierungskriterien.

---

## 4.2 Stable Identity

Jedes persistente Aggregate besitzt genau eine stabile Identität.

Diese Identität bleibt über den gesamten Lebenszyklus unverändert.

Persistente Beziehungen werden ausschließlich über diese fachlichen Identitäten hergestellt.

---

## 4.3 Persistence Ignorance

Das Domain Model kennt keine Persistenz.

Fachliche Aggregate enthalten insbesondere keine Kenntnisse über

- Datenbanken,
- SQL,
- Repositorys,
- Persistenzframeworks,
- Speichertechnologien.

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

---

## 4.4 Separation of Concerns

Persistenz dient ausschließlich der dauerhaften Speicherung fachlicher Zustände.

Sie ersetzt weder fachliche Regeln noch Entscheidungslogik.

Fachliche Invarianten bleiben Bestandteil des Domain Models beziehungsweise der koordinierenden Application Services.

---

## 4.5 Immutable Provenance

Die Provenienz eines SourceValue gehört zu seiner fachlichen Identität.

Die Beziehung

SourceSystem

↓

SourceDelivery

↓

SourceValue

bleibt nach erfolgreicher Persistierung unveränderlich.

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 oder zusätzliche persistente Informationen sollen ergänzt werden können,

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

---

# 5. Persisted Aggregates

Die folgenden Aggregate besitzen einen dauerhaft persistenten Zustand.

| Aggregate Root | Responsibility |
|----------------|----------------|
| SourceSystem | beschreibt das fachliche Ursprungssystem |
| SourceDelivery | beschreibt eine konkrete Datenlieferung |
| SourceValue | beschreibt den unveränderten Eingangswert einschließlich seiner InterpretationGraphs und InterpretationNodes |
| ReconciliationResult | beschreibt einen Reconciliation-Versuch einschließlich CandidateItems und MatchDecisions |


Die übrigen fachlichen Objekte werden innerhalb ihrer jeweiligen Aggregate persistiert.

---

# 6. Aggregate Dependencies

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

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

Das Diagramm beschreibt ausschließlich fachliche Persistenzabhängigkeiten.

Es trifft keine Aussage über deren technische Umsetzung.

---

# 7. Provenance Model

Mit ADR002 wurde die Provenienz als eigenständiger Bestandteil des fachlichen Modells eingeführt.

Der persistente Ursprung eines SourceValue ergibt sich aus der unveränderlichen Beziehung zwischen

- SourceSystem,
- SourceDelivery
- und SourceValue.

Diese Struktur gewährleistet die dauerhafte Nachvollziehbarkeit eines Eingangswertes über seinen gesamten Lebenszyklus.

---

# 8. Status nach Teil 1

Teil 1 definiert

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

Die folgenden Kapitel beschreiben den dauerhaft zu speichernden Zustand der einzelnen Aggregate.

# 9. Aggregate: SourceSystem

## Responsibility

SourceSystem beschreibt das fachliche Ursprungssystem einer oder mehrerer Datenlieferungen.

Es repräsentiert die langfristige Identität einer Quelle unabhängig von einzelnen Importvorgängen oder technischen Schnittstellen.

Beispiele sind Sammlungsmanagementsysteme, Repositorien oder andere Datenquellen.

---

## Persisted State

Der dauerhaft zu speichernde Zustand umfasst insbesondere

| Persisted Property | Meaning |
|--------------------|---------|
| Identity | Eindeutige Identität des SourceSystems |
| Name | Fachliche Bezeichnung |
| Stable URI | Optionale dauerhafte Identifikation |

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

---

## Relationships

Ein SourceSystem kann Grundlage mehrerer SourceDeliveries sein.

---

# 10. Aggregate: SourceDelivery

## Responsibility

SourceDelivery beschreibt eine konkrete Lieferung eines SourceSystems.

Sie bildet die fachliche Einheit einer Datenübernahme und verbindet alle zugehörigen SourceValues mit ihrer gemeinsamen Provenienz.

---

## Persisted State

| Persisted Property | Meaning |
|--------------------|---------|
| Identity | Eindeutige Identität der Lieferung |
| SourceSystem Reference | Referenz auf genau ein SourceSystem |
| Delivery Channel | Fachlicher Lieferkanal als Value Object |
| External Delivery Identifier | Optionale externe Kennung |
| Reception Timestamp | Zeitpunkt des Eingangs |

DM002 trifft bewusst keine Aussage darüber,

- wie DeliveryChannel persistiert wird,
- ob hierfür einzelne Attribute,
- strukturierte Datentypen
- oder spätere Referenzstrukturen verwendet werden.

Diese Entscheidung gehört zur Implementierung.

---

## Relationships

Jede SourceDelivery gehört genau zu einem SourceSystem.

Eine SourceDelivery kann mehrere SourceValues enthalten.

---

# 11. Aggregate: SourceValue

## Responsibility

SourceValue beschreibt den unveränderten fachlichen Eingangswert.

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

---

## Persisted State

| Persisted Property | Meaning |
|--------------------|---------|
| Identity | Eindeutige Identität |
| SourceDelivery Reference | Referenz auf genau eine SourceDelivery |
| Original Value | Ursprünglicher Eingangswert |
| Original Language | Optionale Ursprungssprache |
| Metadata | Optionale fachliche Zusatzinformationen |

Der ursprüngliche Eingangswert bleibt dauerhaft unverändert.

---

## Relationships

Jeder SourceValue gehört genau zu einer SourceDelivery.

Aus einem SourceValue können mehrere InterpretationGraphs entstehen.

---

# 12. Aggregate: InterpretationGraph

## Responsibility

InterpretationGraph beschreibt eine vollständige fachliche Interpretation eines SourceValue.

Er bildet die Wurzel sämtlicher Interpretationsknoten.

Mehrere InterpretationGraphs können unterschiedliche fachliche Sichtweisen desselben SourceValue repräsentieren.

---

## Persisted State

| Persisted Property | Meaning |
|--------------------|---------|
| Identity | Eindeutige Identität |
| SourceValue Reference | Referenz auf den interpretierten Eingangswert |
| Status | Fachlicher Bearbeitungsstatus |
| Version | Optionale Version |
| Creation Information | Entstehungsinformationen |

---

## Relationships

Ein InterpretationGraph gehört genau zu einem SourceValue.

Er enthält einen oder mehrere InterpretationNodes.

---

# 13. Aggregate: InterpretationNode

## Responsibility

InterpretationNode beschreibt einen einzelnen fachlichen Interpretationsschritt innerhalb eines InterpretationGraph.

Mehrere Nodes bilden gemeinsam den vollständigen Interpretationsbaum.

---

## Persisted State

| Persisted Property | Meaning |
|--------------------|---------|
| Identity | Eindeutige Identität |
| InterpretationGraph Reference | Zugehöriger InterpretationGraph |
| Parent Reference | Optionale Beziehung zum übergeordneten Node |
| Interpreted Value | Fachlich interpretierter Wert |
| Interpretation Property | Fachliche Bedeutung des Knotens |
| Status | Bearbeitungsstatus |

Die Definition möglicher Interpretation Properties erfolgt ausschließlich in ME001.

DM002 beschreibt lediglich deren dauerhafte Speicherung.

---

## Relationships

Ein InterpretationNode gehört genau zu einem InterpretationGraph.

Nodes können rekursive Parent-Child-Beziehungen bilden.

Ein InterpretationNode kann Grundlage mehrerer ReconciliationResults sein.

Die ReconciliationResults gehören dabei jeweils zu eigenständigen ReconciliationResult-Aggregaten.

---

# 14. Aggregate: ReconciliationResult

## Responsibility

ReconciliationResult beschreibt einen einzelnen fachlichen Reconciliation-Versuch.

Es dokumentiert den vollständigen Kontext eines Matching-Prozesses.

---

## Persisted State

| Persisted Property | Meaning |
|--------------------|---------|
| Identity | Eindeutige Identität |
| InterpretationNode Reference | Ausgangspunkt des Reconciliation-Versuchs |
| Target Vocabulary | Zielvokabular |
| Matching Pattern | Fachliche Bewertung nach ME001 |
| Creation Information | Entstehungsinformationen |

---

## Relationships

Ein ReconciliationResult gehört genau zu einem InterpretationNode.

Es kann mehrere CandidateItems sowie eine oder mehrere MatchDecisions enthalten.

---

# 15. Aggregate: CandidateItem

## Responsibility

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

CandidateItems besitzen außerhalb ihres zugehörigen ReconciliationResult keine eigenständige fachliche Identität.

---

## Persisted State

| Persisted Property | Meaning |
|--------------------|---------|
| Identity | Eindeutige Identität innerhalb des ReconciliationResult |
| Candidate URI | Identifikation des Kandidaten |
| Display Label | Menschlich lesbare Bezeichnung |
| Candidate Provider URI | Herkunft des Kandidaten |
| Score | Optionale Bewertung |

---

## Relationships

Jedes CandidateItem gehört genau zu einem ReconciliationResult.

---

# 16. Aggregate: MatchDecision

## Responsibility

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

Sie dokumentiert sowohl automatische als auch manuelle Entscheidungen.

---

## Persisted State

| Persisted Property | Meaning |
|--------------------|---------|
| Identity | Eindeutige Identität |
| ReconciliationResult Reference | Zugehöriger Reconciliation-Versuch |
| Decision | Fachliche Entscheidung |
| Selected Candidate | Optional ausgewählter Kandidat |
| Decision Information | Zeitpunkt und Verantwortlichkeit |

---

## Relationships

Jede MatchDecision gehört genau zu einem ReconciliationResult.

Mehrere Entscheidungen können den Verlauf einer fachlichen Bewertung dokumentieren.

---

# 17. Status nach Teil 2

Mit Teil 2 sind sämtliche persistenten Aggregate beschrieben.

Für jedes Aggregate wurden

- seine fachliche Verantwortung,
- der dauerhaft zu speichernde fachliche Zustand
- sowie seine fachlichen Beziehungen

definiert.

Die folgenden Kapitel beschreiben die logischen Integritätsregeln und Persistenzprinzipien der Gesamtarchitektur.


# 18. Persistence Integrity

Das Persistenzmodell stellt sicher, dass ausschließlich fachlich konsistente Zustände dauerhaft gespeichert werden.

Reconcilix unterscheidet dabei bewusst zwischen

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

Diese Ebenen ergänzen sich, besitzen jedoch unterschiedliche Verantwortlichkeiten.

---

## 18.1 Technical Integrity

Die Persistenz gewährleistet die eindeutige Identifizierbarkeit aller persistenten Aggregate.

Insbesondere müssen

- persistente Identitäten eindeutig sein,
- Referenzen auf bestehende Aggregate verweisen,
- obligatorische persistente Eigenschaften vorhanden sein.

Die konkrete technische Umsetzung dieser Anforderungen bleibt Bestandteil der Implementierung.

---

## 18.2 Structural Integrity

Die Beziehungen zwischen den Aggregaten bleiben dauerhaft erhalten.

Insbesondere gelten folgende fachliche Abhängigkeiten:

```text
SourceSystem
        │
        ▼
SourceDelivery
        │
        ▼
SourceValue
```

sowie

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

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




Diese Struktur beschreibt ausschließlich fachliche Persistenzabhängigkeiten.

Sie trifft keine Aussage über deren technische Umsetzung.

---

## 18.3 Domain Integrity

Nicht alle fachlichen Regeln lassen sich unmittelbar durch die Persistenz gewährleisten.

Beispiele sind

- zulässige Vocabulary Matching Patterns,
- vollständige SourceDeliveries,
- genau eine fachlich gültige finale MatchDecision,
- Konsistenz eines InterpretationGraph.

Diese Regeln werden durch das Domain Model sowie die koordinierenden Application Services sichergestellt.

DM002 dokumentiert diese fachlichen Anforderungen, übernimmt jedoch keine Aussagen über deren technische Durchsetzung.

---

# 19. Persistent Identity

Alle persistenten Aggregate besitzen eine dauerhaft stabile fachliche Identität.

Diese Identität

- bleibt über den gesamten Lebenszyklus unverändert,
- wird niemals wiederverwendet,
- dient ausschließlich der eindeutigen Identifikation eines Aggregates.

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

Entsteht fachlich ein neues Objekt,

entsteht ebenfalls eine neue persistente Identität.

---

# 20. Persistent Relationships

Persistente Beziehungen beschreiben die dauerhaft gültigen fachlichen Verknüpfungen zwischen Aggregaten.

Alle Beziehungen orientieren sich unmittelbar am Domain Model. Aggregate-übergreifende Beziehungen werden ausschließlich über stabile Referenzen zwischen den jeweiligen Aggregate Roots hergestellt.

Die Persistenz gewährleistet, dass diese Beziehungen dauerhaft konsistent bleiben.

Die fachliche Reihenfolge ergibt sich aus den Abhängigkeiten der Aggregate.

Sie beschreibt ausdrücklich

- keine Repository-Reihenfolge,
- keine SQL-Reihenfolge,
- keine technische Speicherreihenfolge.

---

# 21. Provenance Consistency

Die Provenienz eines SourceValue bleibt nach erfolgreicher Persistierung unveränderlich.

Neue Reconciliation-Läufe verändern niemals die Herkunft eines bereits persistierten SourceValue.

Sie erweitern ausschließlich dessen fachlichen Interpretationszustand.

Dadurch bleiben Herkunft und Interpretation dauerhaft voneinander getrennt.

---

# 22. Lifecycle Principles

Die Aggregate besitzen unterschiedliche fachliche Lebenszyklen.

Dabei entstehen zwei klar getrennte Bereiche.

## Provenance

```text
SourceSystem

↓

SourceDelivery

↓

SourceValue
```

Diese Aggregate beschreiben die Herkunft eines Eingangswertes.

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

---

## Interpretation

```text
InterpretationGraph

↓

InterpretationNode

↓

ReconciliationResult

↓

CandidateItem

↓

MatchDecision
```

Diese Aggregate entstehen während der Interpretation und können durch spätere Reconciliation-Läufe erweitert werden.

Die Provenienz bleibt hiervon unberührt.

---

# 23. Evolution Principles

Die Persistenzarchitektur unterstützt zukünftige Erweiterungen,

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

Insbesondere sollen ergänzt werden können

- zusätzliche Candidate Provider,
- weitere Knowledge Sources,
- neue Discovery-Verfahren,
- alternative Matching-Strategien,
- zusätzliche persistente Aggregate.

Die bestehenden fachlichen Beziehungen bleiben hiervon möglichst unberührt.

---

# 24. Architectural Constraints

Die logische Persistenzarchitektur folgt den folgenden Grundsätzen.

- Persistiert wird ausschließlich fachlicher Zustand.
- Persistenz ersetzt keine fachliche Logik.
- Persistenz bleibt unabhängig von konkreten Technologien.
- Persistente Beziehungen folgen ausschließlich dem Domain Model.
- Fachliche Aggregate bleiben unabhängig von ihrer technischen Speicherung.

Diese Grundsätze bilden den Rahmen für sämtliche zukünftigen Implementierungen.

---

# 25. Status nach Teil 3

Mit Teil 3 sind

- Persistenzintegrität,
- persistente Identitäten,
- persistente Beziehungen,
- Provenienzkonsistenz,
- Lebenszyklen
- sowie architektonische Randbedingungen

vollständig beschrieben.

Die abschließenden Kapitel behandeln die langfristige Einordnung des Persistenzmodells innerhalb der Reconcilix-Architektur.

# 26. Deferred Design

DM002 beschreibt bewusst ausschließlich die gegenwärtige logische Persistenzarchitektur.

Die folgenden Themen werden als wahrscheinliche Weiterentwicklungen betrachtet, sind jedoch nicht Bestandteil der aktuellen Architektur.

---

## 26.1 Additional Knowledge Sources

Die Architektur ist darauf ausgelegt, künftig weitere Wissensquellen zu integrieren.

Beispiele sind

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

Diese Erweiterungen sollen möglich sein, ohne bestehende persistente Aggregate grundlegend verändern zu müssen.

---

## 26.2 Additional Discovery Strategies

Das Persistenzmodell ist unabhängig von den Verfahren zur Candidate Discovery.

Zukünftige Discovery-Strategien können beispielsweise auf

- Embeddings,
- Vector Search,
- Large Language Models,
- regelbasierten Verfahren
- oder externen Reconciliation Services

beruhen.

DM002 beschreibt ausschließlich den dauerhaft gespeicherten fachlichen Zustand dieser Verfahren, nicht deren Ausführung.

---

## 26.3 Aggregate Evolution

Neue fachliche Aggregate können ergänzt werden, sofern sie den bestehenden Verantwortlichkeiten eindeutig zugeordnet werden können.

Dabei gelten weiterhin die Grundprinzipien dieses Dokuments:

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

---

## 26.4 Alternative Persistence Technologies

DM002 beschreibt ein logisches Persistenzmodell.

Es trifft daher bewusst keine Aussage darüber, ob der persistente Zustand künftig beispielsweise in

- relationalen Datenbanken,
- Dokumentdatenbanken,
- Graphdatenbanken
- oder anderen Persistenztechnologien

gespeichert wird.

Entscheidend ist ausschließlich die Einhaltung der in diesem Dokument beschriebenen fachlichen Persistenzprinzipien.

---

# 27. Design Rationale

Die logische Persistenzarchitektur verfolgt vier grundlegende Ziele.

---

## Fachliche Stabilität

Der dauerhaft gespeicherte Zustand orientiert sich ausschließlich am Domain Model.

Technologische Entscheidungen beeinflussen die fachliche Struktur nicht.

Dadurch bleibt die Persistenzarchitektur langfristig stabil.

---

## Klare Verantwortlichkeiten

Jedes Aggregate besitzt eine eindeutig abgegrenzte fachliche Verantwortung.

Persistenz speichert fachlichen Zustand.

Fachliche Entscheidungen bleiben Aufgabe der Domain.

Technische Umsetzung bleibt Aufgabe der Implementierung.

---

## Langfristige Erweiterbarkeit

Neue Wissensquellen,

zusätzliche Discovery-Verfahren

oder weitere Matching-Strategien

können ergänzt werden,

ohne die bestehenden fachlichen Aggregate grundlegend verändern zu müssen.

---

## Technologieunabhängigkeit

Die Architektur beschreibt Anforderungen an den dauerhaft zu speichernden fachlichen Zustand.

Sie schreibt keine konkrete Persistenztechnologie vor.

Dadurch bleibt Reconcilix unabhängig von zukünftigen technologischen Entwicklungen.

---

# 28. Relationship to Other Documents

Die Architektur von Reconcilix besteht aus mehreren klar abgegrenzten Dokumentebenen.

```text
ADR001
Grundsatzentscheidungen

        │
        ▼

ADR002
Source Architecture

        │
        ▼

DM001
Domain Model

        │
        ▼

DM002
Logical Persistence Model

        │
        ▼

WP2
Persistence Implementation
```

Jedes Dokument beantwortet eine eigenständige Architekturfrage.

| Document | Central Question |
|----------|------------------|
| ADR001 | Welche grundlegenden Architekturentscheidungen gelten? |
| ADR002 | Wie wird die Provenienz fachlich modelliert? |
| DM001 | Welche fachlichen Aggregate existieren? |
| DM002 | Welcher fachliche Zustand wird dauerhaft gespeichert? |
| WP2 | Wie wird dieser Zustand technisch persistiert? |

Diese Schichtung reduziert Kopplungen zwischen Fachmodell und Implementierung und erleichtert die langfristige Wartbarkeit der Gesamtarchitektur.

---

# 29. Conclusion

DM002 beschreibt die logische Persistenzarchitektur von Reconcilix.

Es definiert den dauerhaft zu speichernden fachlichen Zustand sämtlicher persistenter Aggregate und deren Beziehungen.

Gemeinsam mit

- ADR001,
- ADR002
- und DM001

entsteht eine Architektur,

in der

- fachliche Modellierung,
- logische Persistenz
- und technische Umsetzung

klar voneinander getrennt sind.

Diese Trennung ermöglicht eine langfristig stabile und erweiterbare Architektur für Reconciliation-Prozesse im Bereich semantischer Datenintegration.

---

# Document History

| Version   | Status | Description |
|-----------|--------|-------------|
| 0.1       | Draft | Initial persistence model |
| 0.2       | Draft | Aggregate structure refined |
| 0.3       | Draft | Candidate model revised |
| 0.4       | Draft | Complete persistence model |
| 0.5       | Draft ED | Separation of persistence and implementation |
| 0.5 ED-LA | Draft | Refined as logical persistence model following architecture review |
| 0.6       | Draft | Aggregate Boundary aligned with ADR001 |