Dependency Injection & Registration
Relevant source files
The following files were used as context for generating this wiki page:
Dependency Injection (DI) and registration in the MCB project are governed by Clean Architecture principles, ensuring that dependencies flow strictly inward toward the domain layer. The system utilizes a "static DI" or containerless architecture approach where infrastructure collaborators are injected into domain ports, avoiding hidden globals or hard-wired construction inside business logic.
The core of this system is built on the linkme crate, which provides a distributed slice mechanism for compile-time provider discovery and registration. This allows the mcb-infrastructure layer to handle composition and runtime wiring by resolving concrete implementations for domain-defined interfaces (ports) through an opaque application context.
Sources: AGENTS.md:65-68, README.md:104-106, crates/mcb-domain/src/lib.rs:25-33
Architecture Layers & Dependency Flow
The project enforces strict layer boundaries where the domain remains independent of technical concerns. Registration happens at the infrastructure level, bridging the gap between high-level policy and low-level detail.
| Layer | DI Responsibility | Dependencies Allowed |
|---|---|---|
| mcb-domain | Defines Port traits (interfaces) and the registry for auto-registration. | Zero internal dependencies. |
| mcb-providers | Implements domain ports (adapters for DB, vector stores, etc.). | mcb-domain, mcb-utils. |
| mcb-infrastructure | Composition root; wires implementations to ports using linkme. | mcb-domain, mcb-providers, mcb-utils. |
| mcb-server | Resolves services via DI context to handle MCP protocol requests. | mcb-infrastructure, mcb-domain, mcb-utils. |
Sources: AGENTS.md:204-225, README.md:91-102, crates/mcb/Cargo.toml:44-59
Dependency Flow Diagram
The following diagram illustrates how dependencies flow inward, while registration mechanisms allow the outer layers to fulfill the requirements of the inner layers.
The diagram shows that while mcb-server uses the context, the context itself points to abstractions defined in the mcb-domain, which are implemented by mcb-providers.
Sources: AGENTS.md:204-215, crates/mcb-domain/src/lib.rs:25-33
Static DI and Registry Mechanism
MCB uses a distributed slice-based registration system. This "Containerless Architecture" avoids the overhead of traditional runtime DI containers while maintaining decoupling.
Service Resolution Context
The ServiceResolutionContext acts as an opaque carrier for infrastructure dependencies such as database connections and configuration. It allows these dependencies to move through the domain layer without creating cyclic dependencies between mcb-infrastructure and mcb-domain.
linkme Registration
The project utilizes the linkme crate to register providers into a central catalog. At compile-time, providers are "linked" to the domain using distributed slices. This ensures zero runtime overhead for service discovery.
This sequence highlights the decoupling between the implementation of a provider and its eventual resolution during the application bootstrap.
Sources: crates/mcb-domain/src/lib.rs:25-33, crates/mcb-providers/Cargo.toml:68-69, crates/mcb-infrastructure/Cargo.toml:84
Configuration Injection
The DI system is integrated with the Loco framework's configuration management. MCB-specific settings are deserialized into an AppConfig model, which is then injected into the infrastructure collaborators.
- Profiles: Configuration varies by environment (Development, Test, Production), but the DI registration logic remains consistent across profiles.
- Settings Mapping: Sections under
settings:in YAML files are mapped to the typed configuration used by providers.
Sources: AGENTS.md:231-245, crates/mcb-server/Cargo.toml:104-106
Summary
The Dependency Injection and Registration system in MCB is a foundational element of its Clean Architecture implementation. By utilizing compile-time registration with linkme and an opaque ServiceResolutionContext, the project ensures that business logic remains pure and decoupled from infrastructure. This architecture facilitates high testability and allows for easy swapping of providers—such as changing vector stores or embedding models—without modifying the core domain code.
Sources: AGENTS.md:65-68, crates/mcb-domain/src/lib.rs:11-20