mfe-skills / rules

---
description: Micro-frontend architecture: MFE boundary rules — quick reference. Load when this topic is in scope; part of mfe-skills.
alwaysApply: false
---

# MFE boundary rules — quick reference

**Version**: 1.2 | **Skill**: understanding-mfe-architecture | **Full rules**: load reviewing-mfe-boundaries skill

For full rule definitions, violation signals, and code-checkable patterns across all toolchains (React, Angular/Native Federation, Module Federation v1/v2, Single SPA), load `reviewing-mfe-boundaries` skill.

## Boundary health check

Use this checklist when reviewing whether existing boundaries are well-formed. A well-formed boundary satisfies all seven:

1. Is the API surface minimal — fewer than 5 props to the container?
2. Is the micro-frontend context-aware — does it retrieve its own data given minimal input?
3. Is it less extensible than a component — not designed for reuse across domains?
4. Is it coarse-grained — not fine enough to require constant coordination with its container?
5. Can it deploy without coordinating with other teams?
6. Does it have a graceful fallback if it fails to load?
7. Does a single team own it end-to-end?

If any answer is no, the boundary needs to be revisited before implementation begins.

## Rule summary

| Rule | Core principle | Primary violation signal |
|---|---|---|
| 1 — Business subdomain | Represents a domain, not a UI element | Named after UI element; reused across domains |
| 2 — Minimal API surface | Fewer than 5 props; identifiers not objects | Domain objects passed as props; container fetches data for the MFE |
| 3 — Hide implementation details | API contract agreed upfront; internals hidden | Direct import from another MFE's package |
| 4 — Events not shared state | Event emitter or storage only; no shared state managers | Redux/Zustand/MobX shared across MFE boundaries |
| 5 — Independent deployment | No versioned URL pinning; no build-time coupling | Shell hard-codes versioned remote URL; CI `needs:` coupling |
| 6 — Isolate failure | Fallback in shell for every remote mount | No fallback at mount point in the shell |
| 7 — Coarse-grained | Max 3 MFEs per view; shell first segment via manifest; MFE hardcodes sub-routes | Shell owning `/catalog/product/:id`; shell hard-coded MFE routes; shell `catalog:*` handlers |
| 8 — Single-team ownership | One team owns full lifecycle | Multiple teams in CODEOWNERS for same MFE |

## Additional governance extensions

These complement (not replace) the eight boundary rules:

| Extension | Principle | Primary violation signal |
|---|---|---|
| Feature flags scope | Flags stay inside owning MFE for behaviour rollout | Shell/runtime toggles selecting fine-grained MFE behaviour |
| Edge strategy | Use edge when it improves routing/rollout outcomes | Edge rendering adopted with no latency or rollout benefit |
| SSR ownership | Split by route/domain; teams own compute for their pages | SSR infra centralised while domain ownership is ambiguous |
| Browser composition in SSR | RSC/Islands still require coarse boundaries | Fragment-level decomposition causing shell coordination logic |
| Fitness functions | Enforce boundaries continuously in CI | No tests for cross-MFE imports or shared allowlist drift |