A modular architecture for
DMA tells people and agents where frontend code lives and verifies boundaries through the linter, CLI, and CI.
Agent
Reading derived-modular skill
layers · imports · public
+3 −1 features/checkout/public/api.ts
$npx @derived-modular/cli check .
12 modules scanned
1 signal · stage-growth · checkout
- Install
- dma check
- Deploy
Four boundaries in src/
No components/, utils/, or ad-hoc folders by taste. The folder tree is the rulebook; linter and CI enforce it. One-way imports: a lower layer never imports a higher one.
├─ app/
Entry point: routes and pages where the app starts.
├─ features/
Product flows mounted from app: catalog, checkout. No inbound edges from other modules; may import services and shared.
├─ services/
Shared product scenarios other modules depend on. Promoted when a second module needs the same code — e.g. catalog and checkout import services/cart.
└─ shared/
Portable helpers and UI: dates, buttons, HTTP client.
The layout grows with the product
You do not need the full folder tree on day one. Start with one file and add structure as the code grows.
File module
Start with a single file, checkout.tsx. This module also holds the cart logic.
Boundaries are checked, not debated
Rich tooling won't let you slip: linter, agent, and CLI enforce the same rules.
Problems
import { getCatalog } from "@/features/catalog/public/api";
ESLint
feature-to-feature
checkout → catalog/public/api.ts
terminal
$ npx @derived-modular/cli check .
feature-to-feature
checkout → catalog/public/api.ts
One import graph. The same result in the editor and in CI.
Rules in code, not in chat
Install the CLI, create the folder structure with one command, and check the architecture automatically — the same rules in your editor, your agent, and CI.