# ADR001-WP2-002 -- Composition Root

## LA Review Summary

**Status:** Accepted with minor clarifications\
**Reviewer:** LA\
**Adressat:** ED

------------------------------------------------------------------------

# Gesamturteil

Der Entwurf ist architektonisch konsistent und schließt sauber an
WP2-001 an. Die vorgeschlagene Einführung eines
`ReconciliationCompositionRoot` ist eine konsequente Extraktion der
bereits vorhandenen Objektverdrahtung aus `public/reconcile.php`.

**WP2-002 kann auf dieser Grundlage implementiert werden.**

Es werden keine neuen Architekturkonzepte vorgeschlagen. Die folgenden
Hinweise dienen ausschließlich der Präzisierung der bestehenden
Architektur.

------------------------------------------------------------------------

# 1. ReconciliationCompositionRoot

Die Wahl eines spezifischen

`ReconciliationCompositionRoot`

ist einem generischen `CompositionRoot` vorzuziehen.

Gründe:

-   eindeutige Verantwortlichkeit,
-   Unterstützung zukünftiger Einstiegspunkte (CLI, Batch, Worker,
    Evaluation),
-   Vermeidung eines universellen Infrastruktur-Containers.

------------------------------------------------------------------------

# 2. Trennung der Verantwortlichkeiten

Die Trennung zwischen

-   application-scoped Assembly im Composition Root
-   processing-unit-scoped Assembly in der RuntimeFactory

ist klar und entspricht der bisherigen Architektur.

Der Composition Root erzeugt den stabilen HTTP-Objektgraphen.

Die RuntimeFactory erzeugt pro Verarbeitungseinheit:

-   RuntimeContext
-   tenantbezogene Adapter
-   ReconciliationApplicationService

Diese Trennung sollte unverändert beibehalten werden.

------------------------------------------------------------------------

# 3. Request-Debug-Logging

Das bestehende Request-Debug-Logging kann in WP2-002 im Front Controller
verbleiben.

Begründung:

-   es gehört zur technischen Behandlung des HTTP-Einstiegs,
-   es ist keine Objektverdrahtung,
-   es sollte nicht künstlich in den Composition Root verschoben werden.

Hinweis:

Die bestehende Logging-Lösung sollte außerhalb dieses Workpackages
hinsichtlich möglicher Protokollierung sensibler Informationen (z. B.
API-Key) separat überprüft werden.

------------------------------------------------------------------------

# 4. Composition Root API

Die vorgeschlagene öffentliche API

``` php
createController()
```

ist architektonisch sauber.

Der Composition Root besitzt:

-   keine generische `get()`-Methode,
-   keine öffentliche Service-Auflösung,
-   keine Container-API.

Damit besitzt er keinen Service-Locator-Charakter.

Private Hilfsmethoden zur Strukturierung der Assembly sind ausdrücklich
unkritisch.

------------------------------------------------------------------------

# 5. Configuration

Die Verantwortlichkeiten bleiben klar getrennt.

**Configuration**

-   lädt,
-   validiert,
-   stellt Konfiguration bereit.

**ReconciliationCompositionRoot**

-   verwendet ausschließlich die bereits validierte Configuration,
-   erzeugt den vollständigen Objektgraphen.

Der Composition Root soll keine eigene Konfigurationslogik enthalten.

------------------------------------------------------------------------

# 6. Teststrategie

Zusätzlich zum vorgeschlagenen Test sollte sichergestellt werden:

-   `createController()` funktioniert ohne HTTP-Superglobals,
-   beim Aufbau des Objektgraphen entstehen keine fachlichen
    Seiteneffekte,
-   keine Provider-Aufrufe oder Reconciliation werden bereits während
    der Assembly ausgeführt.

Der bestehende OpenRefine-End-to-End-Test bleibt die maßgebliche
Integrationsprüfung.

------------------------------------------------------------------------

# Zusammenfassung

Die vorgeschlagene Architektur setzt WP2-001 konsequent fort.

Positiv hervorzuheben sind insbesondere:

-   klar abgegrenzter Composition Root,
-   konsequente Constructor Injection,
-   sauber getrennte Objekt-Lebensdauern,
-   keine Einführung eines Frameworks oder DI-Containers,
-   kein Service Locator,
-   vollständige Beibehaltung der bisherigen Dependency Direction.

Die wenigen Hinweise betreffen ausschließlich Klarstellungen und ändern
weder den Workpackage-Schnitt noch die Architekturentscheidung.

------------------------------------------------------------------------

# Review-Ergebnis

**Review Status**

> **Accepted with minor clarifications**

Nach Einarbeitung der genannten Präzisierungen kann **WP2-002** aus
Sicht der Architektur umgesetzt werden.