0017: Leave Dependency Injection to the SD Line

Status

Accepted

Amends ADR-0013: Use Fundle DI Framework in scope only: fundle remains the recommended framework, for the SD line's wiring.

ADR-0013 chose fundle to wire flor's components while flor was one crate written by one line. ADR-0016 divided the code into units — crates whose public APIs humans author and either line implements, held in flor — and the integration that wires them into executables, generated by the SD line in flor-dist.

Wiring the executables is the integration's work, so it is the SD line's, and it is regenerated with the rest of the integration. A unit's public API is a contract both lines implement and every caller reads, so any type in it binds all of them.

Decision

Dependency injection belongs to the SD line. The integration wires the units, and how it does so is not fixed: fundle remains the recommended framework, and the integration may propose another crate, which a human approves like any third-party dependency.

No unit's public API is tied to fundle, or to any other DI framework: no framework type appears in it.

Rationale

A framework type in a unit's API would tie every implementation of the unit, and every caller, to that framework's releases, and fix in a contract a choice the integration may revisit at its next regeneration.

Fundle stays recommended because the reasons ADR-0013 gave hold for the wiring the integration does: construction that can fail, with the error propagated through the graph, and wiring checked at compile time.

Considered:

Keeping ADR-0013 as it stands — every unit's API would carry fundle's types.
Obsoleting ADR-0013 — it drops a recommendation whose reasons still hold.

Consequences

Benefits

A unit's contract outlives any change to how the executables are wired.
The integration can change its wiring at a regeneration without touching a unit.

Trade-offs

The wiring is generated code, held by the suite rather than by review.