Module Boundary Enforcement
This document explains how module boundaries are technically enforced in the admin panel, not just by convention.Why Technical Enforcement?
“At scale, discipline fails.”Your architecture relies on clear boundaries:
- ✅
packages/ui- Pure UI components - ✅
packages/core- Business logic and API calls - ✅
apps/panel- Application that uses both
- ❌ Import
@monorepo/solid-pkg-uifrompackages/core - ❌ Import
@monorepo/solid-pkg-corefrompackages/ui - ❌ Use deep imports like
@monorepo/solid-pkg-ui/src/components/Button
ESLint Rules
We use ESLint’sno-restricted-imports rule to enforce boundaries automatically.
Rule 1: UI Cannot Import Core
Rule 2: Core Cannot Import UI
Rule 3: No Deep Imports
Running the Linter
Check for Violations
Auto-Fix (where possible)
In CI/CD
Add to your CI pipeline:Architecture Diagram
Benefits
1. Prevents Circular Dependencies ✅
Without enforcement:2. Enforces Clean Architecture ✅
- UI Layer: Presentation only
- Core Layer: Business logic only
- App Layer: Orchestration
3. Catches Mistakes Early ✅
- ✅ Fails in development (IDE shows errors)
- ✅ Fails in CI (prevents bad PRs)
- ✅ Clear error messages (explains why it’s wrong)
4. Self-Documenting ✅
The ESLint config serves as documentation:Common Scenarios
Scenario 1: UI Component Needs Data
❌ Wrong:Scenario 2: Core Needs to Show UI
❌ Wrong:Configuration
The ESLint config is located at:Related Documentation
- Module Boundaries - Architecture overview
- Public API - Public API surface
- Adding Features - Where to add code