Overview
Architecture
Internal layering and dependency rules for the Flashboard package.
Flashboard is being built as a modular monolith packaged as a single Composer library. This keeps installation simple while preserving strong internal boundaries between public contracts, core runtime logic, UI payloads, and Laravel-specific integration.
Main layers
Contracts: stable public contracts and builder interfacesCore: package runtime and business-neutral orchestrationUI: rendering-oriented payloads and view-layer structuresIntegration/Laravel: service provider, routing, auth, persistence, discovery, and HTTP bridgeSupport: shared utilities that should not leak framework-specific behavior
Dependency rules
Contractsmay be referenced by every other moduleCoremay depend onContractsandSupportUImay depend onContractsand normalizedCoreoutputIntegration/Laravelmay depend onContracts,Core,UI, and Laravel APIs- host applications should plug in business logic through contracts and configuration, not by editing package internals
Key principles
- Keep the public API declarative and split by concern.
- Keep typed schema nodes package-owned and normalized into deterministic payloads.
- Prefer simple
$form->schema([...])authoring for ordinary CRUD screens. - Preserve escape hatches for advanced workflows and domain-specific behavior.
- Keep business logic in the host application, not inside the reusable package.
Intended folder map
src/
├── Contracts/
├── Core/
├── Integration/
│ └── Laravel/
├── Support/
└── UI/
Why this matters
The package has to do two things at once:
- expose a stable public surface that host applications can depend on
- evolve internal runtime behavior quickly during beta
Strong layering makes that balance much easier. Public contracts can stay deliberate, while internal runtime pieces continue to change behind them.