# DM001_DOMAIN_MODEL_v0.5_DRAFT_ED_LA_REVIEW_SUMMARY **Review Role:** LA (Lead Architect) **Review Status:** Accepted in principle – revision required before finalization ## Gesamtbewertung DM001 v0.5 ist insgesamt sehr stark. ADR002 wurde sauber in das bestehende Domain Model integriert, ohne den Interpretation-and-Reconciliation-Kern zu verändern. Die grundlegende Richtung ist überzeugend. Vor der Freigabe sollten jedoch einige konzeptionelle Punkte präzisiert werden: 1. Die Mindestkardinalität `SourceDelivery → SourceValue [1..*]` ist eine aggregateübergreifende fachliche Vollständigkeitsregel und keine lokal durch das `SourceDelivery` Aggregate erzwingbare Invariante. 2. `DeliveryChannel` sollte für v0.5 eindeutig als Value Object modelliert werden. 3. `candidateSourceSystemUri` sollte in `candidateProviderUri` umbenannt werden. 4. `SourceValue.provenance` sollte noch deutlicher auf wertbezogene Provenienz begrenzt werden. 5. Einige Invarianten sollten ergänzt werden. 6. Die UML sollte entschlackt oder geteilt werden. --- ## 1. SourceDelivery als eigenständiges Aggregate ### Bewertung Die Entscheidung ist überzeugend. `SourceDelivery` besitzt: - eine eigene stabile Identität, - eine Referenz auf genau ein `SourceSystem`, - eigene Lieferungsinformationen, - einen von `SourceValue` unabhängigen Lebenszyklus. Die drei Aggregate ```text SourceSystem SourceDelivery SourceValue ``` sind plausibel getrennt. ### Präzisierung Die Aussage ```text SourceDelivery → SourceValue [1..*] ``` ist keine lokal durch `SourceDelivery` erzwingbare Invariante, weil `SourceValue` ein eigenständiges Aggregate bleibt. Empfohlene Formulierung: > Die Mindestkardinalität ist eine fachliche Vollständigkeitsregel über mehrere Aggregate. Sie wird durch den koordinierenden Application Service an der Transaktionsgrenze sichergestellt. ### Ergebnis **Angenommen.** --- ## 2. DeliveryChannel als Value Object ### Bewertung Für v0.5 ist ein Value Object die richtige Entscheidung. `DeliveryChannel` besitzt: - keine eigene fachliche Identität, - keinen eigenen Lebenszyklus, - keine unabhängige Veränderung, - keine Aggregate-Verantwortung. Er beschreibt ausschließlich eine Eigenschaft einer konkreten `SourceDelivery`. ### Widerspruch im Draft Der Draft beschreibt `DeliveryChannel` gleichzeitig als: - Value Object, - kontrollierten fachlichen Wert, - kontrollierte Klassifikation, - potenzielles Vokabular. Für v0.5 sollte eine klare Arbeitsentscheidung gelten: > `DeliveryChannel` wird als Value Object innerhalb von `SourceDelivery` modelliert. Es kapselt einen kontrollierten Code oder eine URI und besitzt keine eigene Identität. Abschnitt 5.3 sollte entsprechend nicht unter dieselbe Kategorie wie `InterpretationProperty` oder `VocabularyMatchingPattern` gestellt werden. ### Ergebnis **Angenommen für v0.5; konsistente Modellierung erforderlich.** --- ## 3. Aggregate-Grenzen ### Bewertung Die Aggregate-Grenzen sind im Kern sauber. ```text SourceSystem Aggregate SourceDelivery Aggregate SourceValue Aggregate ``` `SourceDelivery` gruppiert `SourceValue`, übernimmt aber nicht deren vollständigen Lebenszyklus. ### Präzisierungen Die Formulierung > Gruppierung der zugehörigen SourceValue könnte so gelesen werden, als halte `SourceDelivery` eine interne Collection. Besser: > Bereitstellung einer stabilen Identität, über die zugehörige `SourceValue` gruppiert werden. Für das `SourceValue` Aggregate sollte statt > Zum fachlichen Innenbereich gehören klarer formuliert werden: > Das `SourceValue` Aggregate umfasst … Die technische Persistenz kann auf mehrere Tabellen und Data Mapper verteilt werden, ohne die fachliche Aggregate-Grenze zu verändern. ### Ergebnis **Sauber, mit kleinen sprachlichen Präzisierungen.** --- ## 4. Neue Invarianten ### Bewertung Die neuen Invarianten sind bereits stark, aber noch nicht vollständig. ### Empfohlene Ergänzungen #### SourceSystem ```text SourceSystem.name ist nicht leer. ``` #### SourceDelivery ```text SourceDelivery.receivedAt ist gesetzt. ``` Semantik: > Zeitpunkt, zu dem Reconcilix die Lieferung angenommen beziehungsweise angelegt hat. #### DeliveryChannel ```text Ein gesetzter DeliveryChannel muss einen gültigen kontrollierten Wert repräsentieren. ``` #### Unveränderlichkeit der Provenienz ```text Die Zuordnung eines SourceValue zu seiner SourceDelivery ist nach Anlage unveränderlich. ``` ```text Die Zuordnung einer SourceDelivery zu ihrem SourceSystem ist nach Anlage unveränderlich. ``` #### Final MatchDecision ```text Ein ReconciliationResult darf höchstens eine fachlich gültige finale MatchDecision besitzen. ``` `externalDeliveryId` sollte derzeit noch nicht als global oder lokal eindeutig festgelegt werden. ### Ergebnis **Weitgehend vollständig; Ergänzungen empfohlen.** --- ## 5. candidateSourceSystemUri ### Bewertung Die Benennung ist verständlich, aber nicht optimal. `SourceSystem` ist nun ein präzise definierter Domain-Begriff für das fachliche Ursprungssystem einer Eingangslieferung. Beim Candidate ist dagegen meist das System oder der Dienst gemeint, der den Candidate bereitstellt. ### Empfehlung ```text candidateProviderUri ``` Definition: > URI des Systems oder Dienstes, der den Candidate für den konkreten Reconciliation-Versuch bereitgestellt hat. Damit ergibt sich eine klare Trennung: ```text SourceSystem → fachliche Herkunft des Eingangswerts targetVocabularyUri → fachliches Zielvokabular candidateProviderUri → Anbieter des Candidates ``` ### Ergebnis **Umbenennung zu `candidateProviderUri` empfohlen.** --- ## 6. SourceValue.provenance ### Bewertung Die Abgrenzung ist deutlich sauberer als zuvor. Positiv ist insbesondere: - `provenance` ersetzt nicht `SourceSystem`, - `provenance` ersetzt nicht `SourceDelivery`, - `provenance` ersetzt nicht `DeliveryChannel`, - Delivery Metadata ist kein `ContextItem`. ### Empfohlene Schärfung > `SourceValue.provenance` enthält ausschließlich ergänzende Provenienzinformationen, die spezifisch für genau diesen `SourceValue` gelten und nicht bereits strukturiert auf Ebene von `SourceSystem`, `SourceDelivery` oder `DeliveryChannel` abgebildet werden. Zusätzlich: > Informationen, die für mehrere oder alle `SourceValue` derselben Lieferung gelten, gehören grundsätzlich zur `SourceDelivery` und sollen nicht redundant in jedem `SourceValue.provenance` gespeichert werden. Eine spätere Umbenennung zu `valueProvenance` oder `additionalProvenance` wäre denkbar, ist aber nicht zwingend erforderlich. ### Ergebnis **Grundsätzlich sauber; Geltungsbereich noch explizit schärfen.** --- ## 7. UML ### Bewertung Die UML ist fachlich weiterhin nachvollziehbar, wird aber visuell zunehmend dicht. ### Empfehlungen Redundante Referenzattribute im Diagramm entfernen, wenn die Association bereits sichtbar ist: - `sourceSystemId` - `sourceDeliveryId` - gegebenenfalls `selectedCandidateUri` Für `DeliveryChannel` als Value Object sollte die Beziehung als Komposition dargestellt werden: ```mermaid SourceDelivery "1" *-- "0..1" DeliveryChannel : transferredVia ``` Empfohlen wird eine Teilung in zwei Diagramme: ### Provenance and Delivery Model ```text SourceSystem │ └── SourceDelivery ─── DeliveryChannel [0..1] │ └── SourceValue [1..*] ``` ### Interpretation and Reconciliation Model ```text SourceValue → InterpretationGraph → InterpretationNode → ReconciliationResult → CandidateItem → MatchDecision ``` Ein vollständiges Gesamtmodell kann optional zusätzlich im Anhang stehen. ### Ergebnis **Fachlich korrekt; Entschlackung oder Aufteilung empfohlen.** --- ## Zusammenfassende Bewertung | Frage | LA-Bewertung | |---|---| | `SourceDelivery` als eigenständiges Aggregate | Ja | | `DeliveryChannel` als Value Object | Ja, für v0.5 | | Aggregate-Grenzen | Sauber | | Neue Invarianten | Stark, aber ergänzungsbedürftig | | `candidateSourceSystemUri` | Umbenennung empfohlen | | `SourceValue.provenance` | Grundsätzlich sauber | | UML-Lesbarkeit | Noch lesbar, Aufteilung empfohlen | --- ## Erforderliche Änderungen vor der Freigabe 1. `SourceDelivery → SourceValue [1..*]` als aggregateübergreifende Vollständigkeitsregel kennzeichnen. 2. `DeliveryChannel` für v0.5 eindeutig als Value Object festlegen. 3. `candidateSourceSystemUri` in `candidateProviderUri` umbenennen. 4. `SourceValue.provenance` auf ausschließlich wertbezogene Provenienz begrenzen. 5. Invarianten zu Pflichtwerten, Unveränderlichkeit der Provenienzreferenzen und finaler `MatchDecision` ergänzen. 6. UML entschlacken oder in zwei Diagramme teilen. --- ## Schlussurteil DM001 v0.5 ist semantisch tragfähig und architektonisch sehr nah an einer freigabefähigen Version. Die grundlegenden Entscheidungen aus ADR002 wurden korrekt umgesetzt. Die offenen Punkte betreffen vor allem Präzision und Konsistenz, nicht die Richtung des Modells. Nach einer Revision entlang dieser Punkte ist eine Freigabe aus LA-Sicht wahrscheinlich.