37 lines
1.4 KiB
Markdown
37 lines
1.4 KiB
Markdown
# ADR-008: Per-Feature InversifyJS Containers
|
|
|
|
**Status:** Accepted
|
|
**Date:** 2026-05-04
|
|
|
|
## Context
|
|
|
|
The original template used a single shared InversifyJS Container in `packages/core/src/di/`. As the number of features grows, the container becomes a point of coordination: adding a symbol requires modifying shared code, and tests that mock one feature risk breaking others.
|
|
|
|
## Decision
|
|
|
|
Each feature owns its own `Container` and symbol table. No shared DI state. Tests rebind per feature in isolation. Apps boot by calling `bindProduction*()` for each feature independently.
|
|
|
|
**Example:**
|
|
```typescript
|
|
// packages/blog/src/di/container.ts
|
|
export const container = createContainer();
|
|
|
|
// packages/blog/tests/feature.test.ts
|
|
beforeEach(() => {
|
|
rebindRepository(new TestRepository());
|
|
// Only blog's container is affected
|
|
});
|
|
```
|
|
|
|
## Consequences
|
|
|
|
- Zero cross-feature DI coupling — each feature's test can mock its repos without coordination
|
|
- Symbol collisions impossible — each feature has its own `ARTICLES_REPOSITORY` symbol
|
|
- Shared services (if needed) are explicitly bound in each feature that uses them
|
|
- Apps must boot each feature's container on startup
|
|
|
|
## Alternatives Considered
|
|
|
|
- Single shared container: Simpler upfront, becomes a bottleneck and test coordination point
|
|
- Function injection (no DI): Avoids framework overhead, but loses the scaling benefits of DI
|