Danijel Martinek
f77e6ea881
Curated, product-agnostic snapshot of the post-story-04 tree: demo content deleted, auth-only reference feature, web-next shell, all gates green. Product-specific docs, ADRs 027-029, PRDs/epics/archive, editor library traces, and product naming are curated out; generic template repairs (coverage provider devDeps, root test:coverage script, live lint fixes, root-only release-please) are kept. See TEMPLATE.md for provenance, curation list, and usage. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_016j8z4VHjedXDTjEDNg7qHK
38 lines
1.4 KiB
Markdown
38 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
|