Press CTRL+K to open search

Module Invariants

  • Published on Aug 26, 2026
  • 1 minute(s) read
  • G
 Prev Next

Module Invariants

  1. Feature Ownership

    • Each module represents a single feature or domain.
    • A module owns the UI composition, interaction logic, and data wiring for its feature.

  2. UI Composition Layer

    • Modules are allowed to return JSX.
    • Modules compose:
      • components from components/
      • data from services/
      • feature-specific state and logic

  3. No Primitive UI Definitions

    • Modules must not define low-level or reusable UI primitives.
    • All shared or generic UI must live in components/.

  4. Service-Driven Data Access

    • Modules must not perform direct API or GraphQL calls.
    • All data access must go through services/.

  5. Controlled Side Effects

    • Side effects are allowed only via services/.
    • Modules must not perform direct network, storage, or global state mutations.

  6. Error Handling Boundary

    • Modules may catch AppError only to:
      • map errors to UI states
      • trigger navigation or recovery flows
    • Modules must not suppress or silently ignore errors.

  7. Explicit Public Surface

    • Internal files must not be imported across modules.