# DM002 — Persistence Model **Version:** 0.4 DRAFT ED **Status:** Draft **Scope:** Relational Persistence Model for Reconcilix Domain Objects **Related Documents** - ADR001 — Domain Integration - ADR002 — Source Delivery Model - IA001 — Impact Analysis ADR002 - DM001 — Domain Model v0.5 - 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 Invarianten definiert, beschreibt DM002 deren dauerhafte Speicherung in einer relationalen Datenbank. Das Dokument ist bewusst unabhängig von einer konkreten ORM-Implementierung formuliert. Die aktuelle Referenzimplementierung verwendet - MySQL 8.x - Doctrine DBAL - Repository Pattern - Data Mapper Pattern Das Persistenzmodell soll jedoch grundsätzlich auch auf andere relationale Datenbanksysteme übertragbar bleiben. DM002 beschreibt ausschließlich die Persistenz fachlicher Zustände. Es beschreibt ausdrücklich nicht - REST-Schnittstellen, - Reconciliation-Protokolle, - OpenRefine, - GUI-Komponenten, - Service-Aufrufe, - Matching-Algorithmen. --- # 2. Scope DM002 beschreibt - relationale Tabellen - Primärschlüssel - Foreign Keys - Persistente Aggregate - Repository-Zuordnungen - referenzielle Integrität - Persistenzregeln - technische Transaktionsgrenzen DM002 beschreibt ausdrücklich nicht - fachliche Matchingregeln - Interpretationstechniken - Candidate Discovery - Matching Patterns - Benutzeroberflächen Diese Aspekte werden in - DM001 - ME001 - ME002 definiert. --- # 3. Architectural Position Die Architektur der Reconcilix-Dokumentation folgt bewusst einer klaren Schichtenbildung. ```text ADR │ ├── Architekturentscheidungen │ ▼ DM001 │ ├── Domain Model │ ▼ DM002 │ ├── Persistence Model │ ▼ WP2 │ ├── Repositories ├── Data Mapper ├── Runtime └── Datenbank ``` DM002 ist somit die verbindende Schicht zwischen Domain Model und Implementierung. Es definiert, - welche Aggregate persistent werden, - wie Aggregate gespeichert werden, - welche Beziehungen technisch abgesichert werden, - welche Regeln ausschließlich durch Application Services gewährleistet werden. --- # 4. Persistence Principles ## 4.1 Aggregate First Die Persistenz orientiert sich ausschließlich an den Aggregaten des Domain Models. Tabellen entstehen nicht aus einer Normalisierung einzelner Attribute, sondern aus fachlichen Verantwortlichkeiten. Damit bleibt die Persistenzstruktur langfristig stabil, auch wenn sich interne Attribute ändern. --- ## 4.2 Aggregate Identity Jedes Aggregate besitzt genau eine persistente Identität. Diese Identität ist dauerhaft stabil. Zwischen Aggregaten werden ausschließlich stabile Identitäten referenziert. Beispiele: ```text SourceDelivery ──► SourceSystem SourceValue ──► SourceDelivery ``` Direkte Objektgraphen werden nicht persistiert. --- ## 4.3 Aggregate Independence Aggregate bleiben unabhängig voneinander. Kein Aggregate besitzt einen direkten Schreibzugriff auf ein anderes Aggregate. Koordination erfolgt ausschließlich über Application Services. Dadurch bleiben - Konsistenz, - Testbarkeit, - Austauschbarkeit der einzelnen Aggregate erhalten. --- ## 4.4 Persistence Ignorance Die Domain kennt keine Datenbank. Domain Objects besitzen keine - SQL-Abhängigkeiten - ORM-Annotationen - Persistenzlogik - Datenbankzugriffe Die Persistenz erfolgt ausschließlich über - Repository - Data Mapper --- ## 4.5 Referential Integrity Referenzielle Integrität wird möglichst durch die Datenbank abgesichert. Hierzu gehören insbesondere - Primary Keys - Foreign Keys - NOT NULL - UNIQUE - CHECK Constraints (soweit unterstützt) Nicht jede fachliche Regel kann jedoch durch relationale Constraints garantiert werden. Beispiele: ```text SourceDelivery → mindestens ein SourceValue ``` oder ```text ReconciliationResult → höchstens eine finale MatchDecision ``` Diese Regeln bleiben bewusst Aufgabe des koordinierenden Application Service. --- ## 4.6 Immutable Provenance Die Herkunft eines Eingangswertes stellt einen wesentlichen Bestandteil seiner fachlichen Identität dar. Nach erfolgreicher Persistierung dürfen deshalb folgende Referenzen nicht mehr verändert werden: ```text SourceDelivery.sourceSystemId SourceValue.sourceDeliveryId ``` Eine Änderung der Provenienz erzeugt fachlich eine neue Lieferung beziehungsweise einen neuen Eingangswert. --- # 5. Aggregate-to-Table Mapping | 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 | Weitere Tabellen dienen ausschließlich - Hilfsstrukturen, - Many-to-Many-Relationen, - Klassifikationen, - technischen Optimierungen. Sie bilden keine eigenen Aggregate. --- # 6. Persistence Model — Source Provenance Die mit ADR002 eingeführten Provenienzobjekte bilden den Einstieg jedes Reconciliation-Vorgangs. Ihre Persistenz folgt unmittelbar der Aggregate-Struktur aus DM001. ```text source_system │ │ 1 │ ▼ source_delivery │ │ 1 │ ▼ source_value ``` Diese Reihenfolge entspricht gleichzeitig der empfohlenen Einfüge-Reihenfolge innerhalb einer Transaktion. --- # 7. Aggregate: SourceSystem ## Responsibility Persistiert das fachliche Ursprungssystem einer oder mehrerer Lieferungen. Beispiele - digiCULT.web - MuseumPlus - Adlib Nicht Bestandteil sind - OpenRefine - REST - CSV - Batch Import Diese gehören zur technischen Lieferung. --- ## Table ```text source_system ``` ### Columns | Column | Meaning | |---------|----------| | id | Primary Key | | name | fachlicher Name | | uri | optionale stabile URI | ### Constraints Primary Key ```text id ``` Empfohlen ```text UNIQUE(uri) ``` falls URI gepflegt wird. --- ## Repository ```text SourceSystemRepository ``` Verantwortlich für - Laden - Speichern - Suchen fachlicher Ursprungssysteme. --- # 8. Aggregate: SourceDelivery ## Responsibility Persistiert eine konkrete Lieferung eines SourceSystems. Eine SourceDelivery besitzt - genau ein SourceSystem, - optional einen DeliveryChannel, - optionale externe Kennungen, - einen Erfassungszeitpunkt. --- ## Table ```text source_delivery ``` ### Columns | Column | Meaning | |---------|----------| | id | Primary Key | | source_system_id | FK | | delivery_channel | Value Object | | external_delivery_id | optionale Kennung | | received_at | Zeitpunkt der Annahme | --- ## DeliveryChannel DeliveryChannel wird bewusst nicht als eigene Tabelle modelliert. Für v0.4 wird das Value Object direkt innerhalb von ```text source_delivery ``` persistiert. Dies entspricht der Entscheidung aus DM001. Eine spätere Auslagerung in ein kontrolliertes Vokabular bleibt möglich, verändert jedoch nicht die Aggregate-Grenzen. --- ## Foreign Key ```text source_delivery.source_system_id REFERENCES source_system(id) ``` Delete Rule ```text RESTRICT ``` Ein SourceSystem darf nicht gelöscht werden, solange Lieferungen darauf verweisen. --- ## Repository ```text SourceDeliveryRepository ``` Verantwortlich für - Anlegen neuer Lieferungen - Laden - Suche - Persistierung --- # 9. Aggregate: SourceValue ## Responsibility Persistiert den unveränderten Eingangswert eines Reconciliation-Prozesses. SourceValue bildet weiterhin den Einstieg in den Interpretation-and-Reconciliation-Kern. Neu gegenüber DM001 v0.4 ist die verpflichtende Zuordnung zu einer SourceDelivery. --- ## Table ```text source_value ``` ### Neue Spalte ```text source_delivery_id ``` ### Foreign Key ```text source_value.source_delivery_id REFERENCES source_delivery(id) ``` Delete Rule ```text RESTRICT ``` Ein SourceValue darf niemals ohne SourceDelivery existieren. --- ## Repository ```text SourceValueRepository ``` Persistiert ausschließlich - SourceValue - ContextItem - InterpretationGraph nicht jedoch fremde Aggregate. --- # 10. Status nach Teil 1 Mit Teil 1 sind die vollständigen Persistenzregeln für - SourceSystem - SourceDelivery - SourceValue definiert. Die folgenden Kapitel beschreiben den Persistenzkern der eigentlichen Reconciliation: - InterpretationGraph - InterpretationNode - ReconciliationResult - CandidateItem - MatchDecision # 11. Persistence Model — Interpretation and Reconciliation Der Interpretation-and-Reconciliation-Kern bleibt gegenüber DM001 fachlich unverändert. Die Persistenz folgt unmittelbar der Aggregate-Struktur. ```text source_value │ ▼ interpretation_graph │ ▼ interpretation_node │ ▼ reconciliation_result │ ├─────────────┐ ▼ ▼ candidate_item match_decision ``` Alle Objekte gehören weiterhin fachlich zum `SourceValue` Aggregate. Sie werden jedoch aus Gründen der Normalisierung und Wartbarkeit auf mehrere relationale Tabellen verteilt. --- # 12. Aggregate: InterpretationGraph ## Responsibility Persistiert genau einen interpretierbaren Ausschnitt eines `SourceValue`. Ein `SourceValue` besitzt fachlich mindestens einen `InterpretationGraph`. Die Persistenz ermöglicht spätere Erweiterungen auf - mehrere Graphen, - alternative Interpretationen, - Versionierungen. --- ## Table ```text interpretation_graph ``` ### Columns | Column | Meaning | |---------|----------| | id | Primary Key | | source_value_id | FK | | span_start | Startposition | | span_end | Endposition | | source_fragment | Originalfragment | | status | Bearbeitungsstatus | | version | Version | | created_at | Erstellungszeitpunkt | --- ## Foreign Key ```text interpretation_graph.source_value_id REFERENCES source_value(id) ``` Delete Rule ```text CASCADE ``` Da InterpretationGraphs ausschließlich innerhalb eines SourceValue existieren, können sie gemeinsam gelöscht werden. --- ## Repository InterpretationGraph wird nicht durch ein eigenes Repository verwaltet. Die Persistierung erfolgt über ```text SourceValueRepository ``` bzw. den späteren ```text InterpretationRepository ``` --- # 13. Aggregate: InterpretationNode ## Responsibility Persistiert einen fachlichen Interpretationszustand innerhalb eines InterpretationGraph. Eine Node besitzt - genau einen Graph, - optional genau eine Parent Node, - beliebig viele Child Nodes. --- ## Table ```text interpretation_node ``` ### Columns | Column | Meaning | |---------|----------| | id | Primary Key | | interpretation_graph_id | FK | | parent_node_id | optionale FK | | value | interpretierter Wert | | level | Ableitungsebene | | status | Status | | created_by | Erzeuger | | technique | verwendete Technik | | note | Erläuterung | | created_at | Zeitstempel | --- ## Foreign Keys ```text interpretation_graph_id REFERENCES interpretation_graph(id) ``` ```text parent_node_id REFERENCES interpretation_node(id) ``` Delete Rule ```text CASCADE ``` für die Beziehung zum Graphen. Die Parent-Child-Beziehung verwendet ```text RESTRICT ``` um inkonsistente Teilgraphen zu vermeiden. --- ## Repository InterpretationNodes werden über das ```text InterpretationRepository ``` persistiert. --- # 14. Controlled Classifications InterpretationNodes können beliebig viele fachliche Eigenschaften besitzen. Diese werden relational getrennt gespeichert. --- ## Table ```text interpretation_node_property ``` ### Columns | Column | Meaning | |---------|----------| | interpretation_node_id | FK | | interpretation_property_uri | URI | --- ## Primary Key ```text ( interpretation_node_id, interpretation_property_uri ) ``` --- ## Foreign Keys ```text interpretation_node_id REFERENCES interpretation_node(id) ``` Die Interpretation Properties selbst werden nicht relational gespeichert. Sie werden über ihre URI referenziert. --- # 15. Aggregate: ReconciliationResult ## Responsibility Persistiert das Ergebnis eines konkreten Reconciliation-Versuchs. Ein InterpretationNode kann mehrere ReconciliationResults besitzen. Beispielsweise - verschiedene Target Vocabularies - unterschiedliche MatchingStrategien - zukünftige LLM-Versuche --- ## Table ```text reconciliation_result ``` ### Columns | Column | Meaning | |---------|----------| | id | Primary Key | | interpretation_node_id | FK | | target_vocabulary_uri | URI | | matching_strategy | Strategie | | success | technisches Flag | | confidence | Bewertung | | note | Erläuterung | | created_at | Zeitstempel | --- ## Foreign Key ```text interpretation_node_id REFERENCES interpretation_node(id) ``` Delete Rule ```text CASCADE ``` --- ## Repository Persistierung über ```text InterpretationRepository ``` --- # 16. Vocabulary Matching Pattern Ein ReconciliationResult kann optional genau ein Vocabulary Matching Pattern besitzen. --- ## Table ```text reconciliation_result_pattern ``` ### Columns | Column | Meaning | |---------|----------| | reconciliation_result_id | FK | | vocabulary_matching_pattern_uri | URI | --- ## Primary Key ```text reconciliation_result_id ``` Da höchstens ein Pattern zulässig ist. --- # 17. Aggregate: CandidateItem ## Responsibility Persistiert einen gefundenen Candidate. Ein Candidate existiert ausschließlich innerhalb eines ReconciliationResult. --- ## Table ```text candidate_item ``` ### Columns | Column | Meaning | |---------|----------| | id | Primary Key | | reconciliation_result_id | FK | | uri | Candidate URI | | display_label | Label | | entity_type | tatsächlicher Entity Type | | candidate_provider_uri | Provider | | score | Score | | rank | Rang | | qualifier | Zusatz | --- ## Foreign Key ```text reconciliation_result_id REFERENCES reconciliation_result(id) ``` Delete Rule ```text CASCADE ``` --- ## Unique Constraint Empfohlen ```text ( reconciliation_result_id, uri ) ``` Damit derselbe Candidate innerhalb eines Runs nicht doppelt gespeichert werden kann. --- ## Repository CandidateItems werden über ```text InterpretationRepository ``` persistiert. --- # 18. Aggregate: MatchDecision ## Responsibility Persistiert eine fachliche oder automatische Entscheidung. Mehrere Entscheidungen dürfen historisch erhalten bleiben. --- ## Table ```text match_decision ``` ### Columns | Column | Meaning | |---------|----------| | id | Primary Key | | reconciliation_result_id | FK | | selected_candidate_uri | optionale URI | | decision | Entscheidung | | confidence | Confidence | | decided_by | Person/System | | comment | Erläuterung | | timestamp | Zeitpunkt | | decision_status | Status | --- ## Foreign Key ```text reconciliation_result_id REFERENCES reconciliation_result(id) ``` Delete Rule ```text CASCADE ``` --- ## selected_candidate_uri Bewusst keine relationale FK. Die Referenz erfolgt fachlich auf einen Candidate desselben ReconciliationResult. Diese Regel wird durch den Application Service validiert. Damit bleibt das Modell flexibel gegenüber zukünftigen externen Candidate-Repositories. --- ## Repository Persistierung über ```text InterpretationRepository ``` --- # 19. Repository Responsibilities Zur Wahrung der Aggregate-Grenzen werden keine Tabellen direkt durch fremde Aggregate verwaltet. Die Verantwortlichkeiten lauten: | Repository | Persistiert | |------------|-------------| | SourceSystemRepository | source_system | | SourceDeliveryRepository | source_delivery | | SourceValueRepository | source_value, context_item | | InterpretationRepository | interpretation_graph, interpretation_node, interpretation_node_property, reconciliation_result, reconciliation_result_pattern, candidate_item, match_decision | Diese Aufteilung folgt unmittelbar den Aggregate-Grenzen aus DM001. Ein Repository darf keine fachlich fremden Aggregate verändern. --- # 20. Status nach Teil 2 Mit Teil 2 ist der vollständige Persistenzkern der Reconciliation beschrieben. Es fehlen nun noch - Foreign-Key-Strategie - Transaktionsgrenzen - Migration - ER-Modell - Deferred Design - Change Summary Diese bilden Teil 3 und Teil 4 des Dokuments. # 21. Referential Integrity DM001 definiert fachliche Invarianten. DM002 legt fest, welche dieser Regeln - durch die relationale Datenbank, - durch Repositorys, - oder durch Application Services sichergestellt werden. Nicht jede fachliche Regel kann oder sollte durch relationale Constraints implementiert werden. --- ## 21.1 Database Constraints Die Datenbank gewährleistet insbesondere - Primary Keys - Foreign Keys - NOT NULL - UNIQUE - Datentypen Diese Regeln werden unabhängig von der Anwendung sichergestellt. --- ## 21.2 Repository Validation Repositories prüfen ausschließlich technische Persistenzregeln. Beispiele - Entity vorhanden - FK referenziert existierende Aggregate - Pflichtattribute vorhanden Repositories treffen ausdrücklich keine fachlichen Entscheidungen. --- ## 21.3 Application Service Validation Komplexe fachliche Regeln werden ausschließlich durch den koordinierenden Application Service garantiert. Hierzu gehören insbesondere ```text SourceDelivery → mindestens ein SourceValue ``` ```text ReconciliationResult → höchstens eine finale MatchDecision ``` ```text selectedCandidate gehört zum selben ReconciliationResult ``` ```text preferredEntityType passt zum Candidate ``` Diese Regeln bleiben unabhängig von der Datenbank. --- # 22. Delete Strategy Reconcilix speichert fachliche Entscheidungen dauerhaft. Daher wird grundsätzlich eine konservative Löschstrategie verwendet. --- ## 22.1 Source Provenance ```text source_system ``` Delete Rule ```text RESTRICT ``` --- ```text source_delivery ``` Delete Rule ```text RESTRICT ``` --- ```text source_value ``` Delete Rule ```text RESTRICT ``` Die Herkunft eines Eingangswertes soll nicht versehentlich gelöscht werden. --- ## 22.2 Interpretation Layer Innerhalb des SourceValue Aggregates gilt dagegen ```text CASCADE ``` ```text interpretation_graph ``` ↓ ```text interpretation_node ``` ↓ ```text reconciliation_result ``` ↓ ```text candidate_item ``` ↓ ```text match_decision ``` Dadurch bleibt das Aggregate intern konsistent. --- # 23. Transaction Boundaries Die Aggregate bleiben unabhängig. Eine fachliche Lieferung entsteht jedoch häufig erst durch das koordinierte Zusammenspiel mehrerer Aggregate. --- ## 23.1 Neue Lieferung Empfohlene Reihenfolge ```text BEGIN SourceSystem (optional) ↓ SourceDelivery ↓ SourceValue ↓ InterpretationGraph ↓ InterpretationNode COMMIT ``` Erst nach erfolgreichem Commit gilt eine Lieferung fachlich als vollständig. --- ## 23.2 Reconciliation Ein Reconciliation-Lauf erzeugt ```text BEGIN ReconciliationResult ↓ CandidateItem ↓ MatchDecision (optional) COMMIT ``` Fehlschläge dürfen keine teilweise persistierten CandidateListen hinterlassen. --- # 24. Repository Collaboration Repositories arbeiten niemals direkt miteinander. Die Koordination erfolgt ausschließlich durch Application Services. ```text Application Service │ ├──────────────┐ ▼ ▼ SourceDeliveryRepository SourceValueRepository InterpretationRepository ``` Repositories besitzen keine Kenntnis voneinander. Dadurch bleiben - Testbarkeit - Austauschbarkeit - Aggregate-Grenzen erhalten. --- # 25. Migration Strategy Die Einführung von ADR002 verändert die Persistenzstruktur. Bestehende Datenbanken müssen daher migriert werden. --- ## Schritt 1 Neue Tabelle ```text source_system ``` anlegen. --- ## Schritt 2 Neue Tabelle ```text source_delivery ``` anlegen. --- ## Schritt 3 Neue Spalte ```text source_value.source_delivery_id ``` hinzufügen. Vorübergehend ```text NULL ``` zulassen. --- ## Schritt 4 Default SourceSystem erzeugen Beispielsweise ```text Legacy Import ``` oder ```text Unknown Source ``` je nach Migrationsstrategie. --- ## Schritt 5 Für bestehende SourceValues eine SourceDelivery erzeugen. --- ## Schritt 6 Alle bestehenden SourceValues dieser SourceDelivery zuordnen. --- ## Schritt 7 Foreign Key aktivieren. --- ## Schritt 8 NOT NULL setzen. Migration abgeschlossen. --- # 26. Persistence UML Das relationale Persistenzmodell ergibt sich wie folgt. ```mermaid erDiagram SOURCE_SYSTEM ||--o{ SOURCE_DELIVERY : contains SOURCE_DELIVERY ||--o{ SOURCE_VALUE : groups SOURCE_VALUE ||--o{ INTERPRETATION_GRAPH : owns INTERPRETATION_GRAPH ||--o{ INTERPRETATION_NODE : contains INTERPRETATION_NODE ||--o{ RECONCILIATION_RESULT : produces RECONCILIATION_RESULT ||--o{ CANDIDATE_ITEM : contains RECONCILIATION_RESULT ||--o{ MATCH_DECISION : receives ``` Dieses Diagramm zeigt ausschließlich - persistente Aggregate, - Tabellen, - Foreign Keys. Fachliche Klassifikationen werden bewusst ausgeblendet. --- # 27. Performance Strategy Die Persistenz wird zunächst auf - Wartbarkeit - Lesbarkeit - fachliche Konsistenz optimiert. Performanceoptimierungen erfolgen ausschließlich nach Bedarf. Empfohlene Indizes ```text source_delivery.source_system_id source_value.source_delivery_id interpretation_graph.source_value_id interpretation_node.interpretation_graph_id reconciliation_result.interpretation_node_id candidate_item.reconciliation_result_id match_decision.reconciliation_result_id ``` Weitere Indizes werden anhand realer Lastprofile ergänzt. --- # 28. Open Questions Die folgenden Fragestellungen bleiben bewusst offen. - Persistierung von Replay Runs - Versionierung kompletter SourceDelivery - Soft Delete - Archivierung - Historisierung - Multi Tenant Betrieb - Event Sourcing - Persistierung von Discovery Runs - Persistierung zukünftiger KnowledgeSource Aggregate - Persistierung zukünftiger DiscoveryChannel Aggregate Diese Punkte werden im Work Package WP3 erneut betrachtet. --- # 29. Status nach Teil 3 Mit Teil 3 sind - relationale Integrität, - Repository-Zusammenarbeit, - Transaktionsgrenzen, - Migration, - Performance, - Persistenzarchitektur vollständig beschrieben. Es verbleiben lediglich - Change Summary - Architekturzusammenfassung - Deferred Design Questions - Dokumenthistorie für Teil 4. # 30. Deferred Design DM002 beschreibt bewusst ausschließlich das Persistenzmodell der aktuellen Architektur. Mehrere Erweiterungen wurden bereits identifiziert, werden jedoch nicht Bestandteil der Version 0.4. Die folgenden Themen bleiben ausdrücklich zukünftigen Architekturentscheidungen vorbehalten. --- ## 30.1 Knowledge Sources Die aktuelle Architektur unterscheidet bereits zwischen - SourceSystem - Candidate Provider - Target Vocabulary Mit zukünftigen Reconciliation-Strategien wird diese Trennung weiter ausgebaut. Beispielsweise - Wikidata - GND - Lobid - QLever - lokale SPARQL-Endpunkte - Vektor-Datenbanken werden künftig vermutlich als eigenständige fachliche Aggregate modelliert. Dies ist nicht Bestandteil von DM002. --- ## 30.2 Discovery Runs Candidate Discovery wird derzeit als Bestandteil eines Reconciliation-Laufs betrachtet. Perspektivisch können Discovery-Prozesse jedoch eigenständig persistiert werden. Dadurch würden beispielsweise möglich - Wiederverwendung früherer Candidate-Suchen - Replay - Vergleich unterschiedlicher Discovery-Verfahren - Benchmarking verschiedener Provider Die Persistierung solcher Discovery Runs bleibt einer zukünftigen Architekturversion vorbehalten. --- ## 30.3 Versionierung Aktuell wird jeweils nur der aktuelle fachliche Zustand persistiert. Nicht Bestandteil von DM002 sind - Versionierung kompletter Aggregate - Historisierung einzelner Änderungen - Event Sourcing - Audit Logs Diese Anforderungen können später ergänzt werden, ohne die Aggregate-Struktur grundsätzlich zu verändern. --- ## 30.4 Multi-Tenant Architecture DM002 geht von einer einzelnen Reconcilix-Installation aus. Mandantenfähigkeit wird bewusst nicht modelliert. Sollte Reconcilix künftig mehrere Organisationen gleichzeitig bedienen, wird hierfür ein separates Architekturkonzept erstellt. --- ## 30.5 Alternative Persistence Technologies DM002 beschreibt ausschließlich relationale Persistenz. Die fachlichen Aggregate bleiben jedoch unabhängig von der Speichertechnologie. Perspektivisch sind daher auch andere Implementierungen denkbar, beispielsweise - PostgreSQL - MariaDB - Cloud SQL - dokumentenorientierte Datenbanken - Graphdatenbanken Die Domain bleibt hiervon unberührt. --- # 31. Design Rationale Das Persistenzmodell folgt konsequent den Grundprinzipien des Domain-Driven Design. Wesentliche Entwurfsentscheidungen sind: - Persistenz orientiert sich an fachlichen Aggregaten. - Repositorys verwalten ausschließlich ihre eigenen Aggregate. - Die Datenbank garantiert technische Integrität. - Fachliche Invarianten werden durch Application Services sichergestellt. - Domain Objects bleiben vollständig persistenzignorant. - Beziehungen zwischen Aggregaten werden ausschließlich über stabile Identitäten hergestellt. Diese Prinzipien erhöhen die Wartbarkeit und erleichtern zukünftige Erweiterungen der Architektur. --- # 32. Change Summary ## Änderungen gegenüber DM002 v0.3 ### Einführung der Provenance-Struktur Neu eingeführt wurden - SourceSystem - SourceDelivery sowie deren Integration in die bestehende Persistenzstruktur. --- ### Neue Foreign Keys Neu hinzugekommen ist ```text source_value.source_delivery_id ``` als verpflichtende Referenz auf die jeweilige Lieferung. --- ### Repository-Struktur überarbeitet Die Verantwortlichkeiten der Repositorys wurden entlang der Aggregate-Grenzen neu definiert. Insbesondere wurde klargestellt, dass Repositorys keine fachlich fremden Aggregate verändern. --- ### Persistence Principles ergänzt Neu aufgenommen wurden architektonische Leitlinien zu - Aggregate Identity - Persistence Ignorance - Referential Integrity - Immutable Provenance - Transaction Boundaries Diese Prinzipien bilden künftig die Grundlage weiterer Persistenzentscheidungen. --- ### Migration beschrieben Erstmals beschreibt DM002 eine empfohlene Migrationsstrategie für bestehende Datenbanken. --- ### Deferred Design ergänzt Mehrere bereits identifizierte Erweiterungen wurden bewusst dokumentiert, ohne sie vorzeitig in die aktuelle Architektur aufzunehmen. Dadurch bleibt die Architektur sowohl stabil als auch offen für zukünftige Entwicklungen. --- # 33. Relationship to other Documents DM002 steht in enger Beziehung zu den übrigen Architektur- und Methodikdokumenten. | Dokument | Beziehung | |----------|-----------| | ADR001 | definiert die grundlegende Domain-Integration | | ADR002 | definiert die Provenance-Struktur (SourceSystem / SourceDelivery) | | IA001 | beschreibt die Auswirkungen von ADR002 auf das Persistenzmodell | | DM001 | definiert Aggregate, Beziehungen und fachliche Invarianten | | ME001 | definiert Interpretation Properties und Vocabulary Matching Patterns | | ME002 | beschreibt den fachlichen Reconciliation-Prozess | DM002 übernimmt keine fachlichen Definitionen aus diesen Dokumenten, sondern beschreibt ausschließlich deren relationale Persistierung. --- # 34. Conclusion Das Persistenzmodell bildet die technische Grundlage für die dauerhafte Speicherung aller fachlichen Zustände innerhalb von Reconcilix. Die Architektur orientiert sich konsequent an den Aggregaten des Domain Models und trennt fachliche Verantwortung klar von technischen Persistenzmechanismen. Durch diese Struktur bleiben - Domain Model, - Persistenz, - Repository Layer - und Application Services weitgehend unabhängig voneinander. Dies erleichtert zukünftige Erweiterungen ebenso wie alternative Persistenztechnologien und neue Reconciliation-Verfahren. DM002 bildet damit die verbindliche Referenz für alle zukünftigen Implementierungen der Persistenzschicht innerhalb von Reconcilix. --- # Document History | Version | Status | Beschreibung | |----------|--------|--------------| | 0.1 | Draft | Erstes Persistenzmodell | | 0.2 | Draft | Erweiterung Interpretation Layer | | 0.3 | Draft | Vorbereitung ADR002 | | 0.4 | Draft ED | Integration des Source Delivery Models, vollständige Überarbeitung der Persistenzprinzipien und Repository-Struktur | --- **End of Document**