# WP3-001-002 – Discovery Configuration Registry

- **Status:** Draft
- **Version:** 0.2
- **Scope:** WP3 – Discovery Framework Foundation
- **Owner:** ED
- **Review:** PL, LA

## Änderungsstand

### Version 0.2

Einarbeitung von LA Review 001.

**Änderungen**

- Auflösung erfolgt über `scopeVocabularyUri`.
- Registry liefert grundsätzlich `DiscoveryRoute[]`.
- Registry gibt ausschließlich aktivierte Discovery Routes zurück.
- Verantwortlichkeiten zwischen Registry und Router geschärft.
- Beispiele um Target Vocabulary und Discovery Scope erweitert.
- KISS-Prinzip beibehalten.

---

## Referenzen

- WP3-001 – Discovery Framework Foundation
- WP3-001-001 – Discovery Route Model
- PRE_WP3-001 – Architekturübersicht Discovery Framework
- ADR002 – Source Delivery Model
- DM001 – Domain Model

---

# 1. Ziel

Dieses Work Package führt die `DiscoveryConfigurationRegistry` ein.

Die Registry stellt die konfigurierten `DiscoveryRoute`-Instanzen zentral bereit und ermöglicht deren Auflösung anhand einer `scopeVocabularyUri`.

Sie liefert grundsätzlich alle passenden aktivierten Discovery Routes (`DiscoveryRoute[]`).

Die Registry enthält keine Routing-Logik und entscheidet nicht, welche von mehreren verfügbaren Discovery Routes verwendet wird.

---

# 2. Scope

Dieses Work Package umfasst ausschließlich

- Einführung der Klasse `DiscoveryConfigurationRegistry`
- Registrierung gültiger `DiscoveryRoute`-Instanzen
- Auflösung von Discovery Routes anhand einer `scopeVocabularyUri`
- Rückgabe aller passenden aktivierten Discovery Routes
- Filterung deaktivierter Discovery Routes
- definierte Behandlung unbekannter Discovery Scopes
- Unit Tests

Nicht Bestandteil sind

- Auswahl einer Discovery Route
- Priorisierung
- Fallback-Regeln
- Adapter-Auflösung
- Candidate Discovery
- Runtime Integration
- persistente Speicherung der Konfiguration

---

# 3. Architekturbezug

Die `DiscoveryConfigurationRegistry` ist Bestandteil des Discovery Frameworks gemäß PRE_WP3-001.

Sie kennt die verfügbaren Discovery Routes, enthält jedoch keine Kenntnisse über Candidate Discovery Adapter oder deren technische Implementierung.

Die Registry liefert grundsätzlich eine Ergebnismenge (`DiscoveryRoute[]`).

Die Auswahl einer einzelnen Discovery Route erfolgt ausschließlich im `CandidateDiscoveryRouter`.

Die Verantwortlichkeiten bleiben getrennt:

```text
DiscoveryConfigurationRegistry
        │
        └── liefert DiscoveryRoute[]

CandidateDiscoveryRouter
        │
        └── wählt genau eine Route aus

CandidateDiscoveryAdapter
        │
        └── führt die technische Discovery aus
```

---

# 4. Klassenübersicht

| Klasse | Typ | Status | Verantwortung |
|---------|-----|--------|----------------|
| `DiscoveryConfigurationRegistry` | Class | Neu | Verwaltet und liefert konfigurierte Discovery Routes |
| `DiscoveryRoute` | Class | Bestehend aus WP3-001-001 | Repräsentiert eine einzelne Discovery-Konfiguration |

---

# 5. Verantwortung der Registry

Die `DiscoveryConfigurationRegistry` ist verantwortlich für

- die Aufnahme gültiger `DiscoveryRoute`-Instanzen,
- die zentrale Verwaltung der konfigurierten Discovery Routes,
- die Auflösung von Discovery Routes anhand einer `scopeVocabularyUri`,
- die Rückgabe aller passenden aktivierten Discovery Routes.

Die Registry ist nicht verantwortlich für

- die Auswahl einer bevorzugten Route,
- Priorisierung,
- Fallback-Regeln,
- die Interpretation einer Discovery Method,
- die Auflösung eines CandidateDiscoveryAdapter,
- die Ausführung einer Discovery-Anfrage,
- Tenant-spezifische Regeln,
- fachliche Match Decisions.

---

# 6. Registrierungsmodell

Die Registry wird zunächst im Arbeitsspeicher aus einer bestehenden PHP-Konfiguration aufgebaut.

Sie erhält beim Erzeugen eine Sammlung gültiger `DiscoveryRoute`-Instanzen.

Beispiel:

```text
DiscoveryConfigurationRegistry

├── target=MCT
│   scope=MCT
│   → xTree JSON API

├── target=MCT
│   scope=MCT/ObjectFacet
│   → Local Reconciliation Store

└── target=MCT
    scope=MCT/ProfessionFacet
    → xTree JSON API
```

Eine persistente Registry oder datenbankgestützte Konfigurationsverwaltung ist nicht Bestandteil dieses Work Packages.

---

# 7. Auflösung nach Discovery Scope

Die Registry stellt alle aktivierten Discovery Routes für eine angefragte `scopeVocabularyUri` bereit.

Beispiel:

```text
scopeVocabularyUri = MCT/ObjectFacet

        │
        ▼

DiscoveryConfigurationRegistry

        │
        ▼

DiscoveryRoute[]
```

Existiert keine aktivierte Discovery Route für den angefragten Discovery Scope, liefert die Registry eine leere Ergebnismenge.

Die Behandlung der Fälle

- keine Route,
- genau eine Route,
- mehrere passende Routes

erfolgt ausschließlich im `CandidateDiscoveryRouter`.

---

# 8. Invarianten

Für die `DiscoveryConfigurationRegistry` gelten folgende Regeln:

1. Die Registry nimmt ausschließlich gültige `DiscoveryRoute`-Instanzen entgegen.
2. Registrierte Discovery Routes werden nicht verändert.
3. Die Auflösung erfolgt über die vollständige `scopeVocabularyUri`.
4. Deaktivierte Discovery Routes werden nicht zurückgegeben.
5. Für eine unbekannte `scopeVocabularyUri` wird eine leere Ergebnismenge zurückgegeben.
6. Die Registry trifft keine Auswahlentscheidung.
7. Die Registry führt keine Candidate Discovery aus.

---

# 9. Implementierungsreihenfolge

1. Klasse `DiscoveryConfigurationRegistry` erstellen.
2. Registrierung von `DiscoveryRoute`-Instanzen implementieren.
3. Auflösung über `scopeVocabularyUri` implementieren.
4. Filterung deaktivierter Discovery Routes ergänzen.
5. Verhalten bei unbekanntem Discovery Scope implementieren.
6. Unit Tests ergänzen.

---

# 10. Deliverables

## Neue Klasse

- `DiscoveryConfigurationRegistry`

## Neue Tests

- `DiscoveryConfigurationRegistryTest`

## Unverändert

- `DiscoveryRoute`
- `CandidateDiscoveryGateway`
- `ReconciliationApplicationService`
- `RuntimeContext`
- `RuntimeFactory`
- Composition Root

---

# 11. Akzeptanzkriterien

Das Work Package ist abgeschlossen, wenn

1. eine Registry mit mehreren `DiscoveryRoute`-Instanzen erzeugt werden kann,
2. alle passenden aktivierten Discovery Routes eines Discovery Scope zurückgegeben werden,
3. Discovery Routes anderer Discovery Scopes nicht im Ergebnis enthalten sind,
4. deaktivierte Discovery Routes nicht zurückgegeben werden,
5. eine unbekannte `scopeVocabularyUri` eine leere Ergebnismenge liefert,
6. die Registry keine Auswahlentscheidung trifft,
7. die Registry keine Adapter- oder Discovery-Logik enthält,
8. alle neuen Unit Tests erfolgreich sind,
9. alle bestehenden Tests weiterhin erfolgreich sind.

---

# 12. Out of Scope

Nicht Bestandteil dieses Work Packages sind

- Priorisierung
- Default Routes
- Fallback Routes
- Auswahl einer Discovery Route
- `CandidateDiscoveryRouter`
- `CandidateDiscoveryAdapterRegistry`
- `CandidateDiscoveryAdapter`
- Local Reconciliation Store Adapter
- xTree Candidate Discovery Adapter
- Runtime Integration
- Persistenz der Discovery Configuration
- Tenant-spezifische Discovery-Konfiguration
- Hybrid Discovery

Diese Funktionen werden erst eingeführt, wenn ein nachfolgendes Work Package sie benötigt.

---

# 13. Auswirkungen auf Folgepakete

## WP3-001-003 – Candidate Discovery Adapter Contract and Registry

Definiert den gemeinsamen technischen Vertrag aller Candidate Discovery Adapter sowie deren Registry.

## WP3-001-004 – Candidate Discovery Router

Verwendet die `DiscoveryConfigurationRegistry`, um alle passenden Discovery Routes eines Discovery Scope zu erhalten.

Die Auswahl einer einzelnen Route erfolgt anschließend im Router.

## WP3-001-005 – Runtime Integration

Erzeugt und verdrahtet die `DiscoveryConfigurationRegistry` innerhalb des produktiven Runtime-Pfads.