Ganz genau. Eine sparsame Struktur lässt sich gezielt erweitern; unnötige Properties entwickeln dagegen schnell einen eigenen Lebenszyklus.

# WP3-001-002 – Discovery Configuration Registry

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

## 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 eines `Target Vocabulary`.

Sie enthält keine Routing-Logik und entscheidet nicht, welche von mehreren verfügbaren 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 der `targetVocabularyUri`
- Filterung deaktivierter Discovery Routes
- definierte Behandlung nicht vorhandener Routes
- Unit Tests

Nicht Bestandteil sind:

- Auswahl einer Route aus mehreren möglichen Routes
- 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 aber keine technischen Kenntnisse über die durch eine Route referenzierten Adapter.

Die Verantwortlichkeiten bleiben getrennt:

```text
DiscoveryConfigurationRegistry
        │
        └── stellt DiscoveryRoute[] bereit

CandidateDiscoveryRouter
        │
        └── verwendet später die bereitgestellten Routes

CandidateDiscoveryAdapter
        │
        └── führt später die technische Discovery aus


Die Registry trifft keine fachliche oder technische Auswahlentscheidung.

---

# 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 Bereitstellung der konfigurierten Routes,
* die Auflösung von Routes anhand einer `targetVocabularyUri`,
* die Rückgabe ausschließlich aktivierter Routes.

Die Registry ist nicht verantwortlich für:

* die Auswahl einer bevorzugten Route,
* die Reihenfolge mehrerer Routes,
* die Interpretation einer Discovery Method,
* die Auflösung eines Technical Adapters,
* die Ausführung einer Discovery-Anfrage,
* Tenant-Berechtigungen,
* 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
    ├── DiscoveryRoute: MCT → xTree
    ├── DiscoveryRoute: MCT → Local Reconciliation Store
    └── DiscoveryRoute: GND → lobid
```

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

---

# 7. Auflösung nach Target Vocabulary

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

Beispiel:

```text
targetVocabularyUri = MCT
        │
        ▼
DiscoveryConfigurationRegistry
        │
        ├── MCT → xTree
        └── MCT → Local Reconciliation Store
```

Existiert keine aktivierte Route für das angefragte Target Vocabulary, liefert die Registry eine leere Ergebnismenge.

Die fachliche Behandlung dieses Zustands erfolgt später durch den `CandidateDiscoveryRouter`.

---

# 8. Invarianten

Für die `DiscoveryConfigurationRegistry` gelten folgende Regeln:

1. Die Registry nimmt ausschließlich gültige `DiscoveryRoute`-Instanzen entgegen.
2. Die Registry verändert registrierte Discovery Routes nicht.
3. Die Auflösung erfolgt über die vollständige `targetVocabularyUri`.
4. Deaktivierte Discovery Routes werden nicht als verfügbare Routes zurückgegeben.
5. Eine unbekannte `targetVocabularyUri` führt zu einer leeren Ergebnismenge.
6. Die Registry bestimmt keine Priorität und keine bevorzugte Route.
7. Die Registry führt keine Candidate Discovery aus.

---

# 9. Implementierungsreihenfolge

1. Klasse `DiscoveryConfigurationRegistry` einführen.
2. Übergabe einer Sammlung von `DiscoveryRoute`-Instanzen ermöglichen.
3. Auflösung nach `targetVocabularyUri` implementieren.
4. Deaktivierte Routes aus dem Ergebnis ausschließen.
5. Verhalten bei unbekannter `targetVocabularyUri` implementieren.
6. Unit Tests ergänzen.

---

# 10. Deliverables

## Neue Klasse

* `DiscoveryConfigurationRegistry`

## Neue Tests

* `DiscoveryConfigurationRegistryTest`

## Unverändert

* `DiscoveryRoute`
* `CandidateDiscoveryGateway`
* `LegacyCandidateDiscoveryAdapter`
* `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 aktivierten Routes eines Target Vocabulary zurückgegeben werden.
3. Routes anderer Target Vocabularies nicht im Ergebnis enthalten sind.
4. Deaktivierte Routes nicht zurückgegeben werden.
5. Eine unbekannte `targetVocabularyUri` eine leere Ergebnismenge liefert.
6. Die Registry keine Prioritäts- oder 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:

* `priority`
* Default Routes
* Fallback Routes
* Auswahl einer Route aus mehreren Treffern
* `CandidateDiscoveryRouter`
* Adapter Registry
* Candidate Discovery Adapter
* Local Reconciliation Store Adapter
* xTree Adapter
* Runtime Integration
* Persistenz der Discovery Configuration
* Tenant-spezifische Konfiguration
* Hybrid Discovery

Diese Funktionen werden nur eingeführt, wenn ein konkretes Folgepaket sie benötigt.

---

# 13. Auswirkungen auf Folgepakete

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

Definiert den gemeinsamen Vertrag für die durch Discovery Routes referenzierten Technical Adapter.

## WP3-001-004 – Candidate Discovery Router

Verwendet die `DiscoveryConfigurationRegistry`, um verfügbare Routes für ein Target Vocabulary zu erhalten und anschließend genau eine geeignete Route mit einem Adapter zusammenzuführen.

## WP3-001-005 – Runtime Integration

Erzeugt und verdrahtet die Registry innerhalb des produktiven Runtime-Pfads.

```

Ein wichtiger KISS-Punkt darin: Die Registry **liefert zunächst mehrere passende Routes zurück, wählt aber keine aus**. Dadurch führen wir weder `priority` noch versteckte Fallback-Regeln ein. Die Auswahl ist später eine klar abgegrenzte Verantwortung des Routers beziehungsweise eines Route Selectors.
```