Clean Architecture React Native AI Template: 3 Layers

Why does architecture matter more with agents?

Blast radius. In a tangled codebase, “regenerate the checkout screen” can rewrite pricing logic that happened to live in the component; in a layered one, the same prompt can only break the checkout screen, because the pricing rules sit in a domain layer the presentation prompt never touches. Boundaries convert “the agent changed something somewhere” into “the agent changed presentation”, which is the difference between a reviewable diff and a frightening one, and it is why the clean architecture tradition, dependencies pointing inward toward pure business rules, found its sharpest modern use case in agent development.

What are the three layers, concretely?

Layer	Contents	May import	Verdict
domain/	Entities as types, use-cases as functions, repository interfaces	Nothing (pure TypeScript)	The protected core; agents rarely touch it
data/	Repository implementations, the one API client, storage, mappers	domain/	Where wire shapes become entities
presentation/	Screens, components, hooks, navigation	domain/ + data/ (via DI seam)	Where generations happen safely

src/
  domain/
    entities/order.ts          // types only
    usecases/place-order.ts    // (deps) => (input) => Result
    repositories/order-repo.ts // the interface: the agents' API
  data/
    repositories/order-repo-impl.ts
    api/client.ts              // the ONE typed client
    mappers/order-mapper.ts    // wire shape -> entity
  presentation/
    features/checkout/         // screens, hooks per feature

The import rule is mechanical and lint-enforceable: domain imports nothing, data imports domain, presentation imports both, and a violation is visible in any diff. Use-cases stay functions with explicit dependencies (placeOrder(repo)(input)), no DI framework, the seam is a parameter, which keeps the pure layer testable without mocking the world, in ordinary React Native TypeScript.

How much ceremony is too much?

More than the boundary’s value. The failure mode of clean architecture content is thirteen folders for a todo app, interfaces with single implementations, and dependency-injection containers in a mobile client; the pragmatic template refuses all of it with one rule: interfaces only where a boundary earns them, and the repositories earn theirs twice, tests fake them, and agents code against them. Everything else stays concrete until a second implementation exists, the same anti-ceremony instinct as the boilerplate decision: architecture serves the blast radius, not the diagram.

Prototypes get an honest exemption: a weekend validation app does not need layers, and retrofitting them after product-market signal is cheaper than ceremonializing every experiment, the structure pays from the third feature onward, which is exactly when agent-generated tangles start compounding.

How do agents work inside the structure?

By contract, outward-in or inward-out, never both at once. Screen prompts carry the use-case signatures (“build the checkout screen from this VP0 design; call placeOrder and calculateTotals from domain; never implement pricing”) and the agent fills presentation against a sealed API. Feature prompts start in domain (“add the refund use-case and the repository method, no UI”) and move outward through data to presentation in separate generations, each layer verified before the next, the staged discipline every large build in this series lands on.

The conventions doc carries the whole thing in five lines, the layer map, the import rule, the repository-as-API instruction, per the folder-structure playbook, and the data layer’s wire shapes stay honest through the JSON-contract discipline, with the one typed client as the single door to the network. Screens themselves generate from free VP0 designs at $0, landing in presentation/features/ where the blast radius was always meant to contain them.

Key takeaways: clean architecture for AI builds

• Three layers, one rule: domain pure, data implements, presentation consumes, dependencies pointing strictly inward.
• Blast radius is the payoff: screen regenerations cannot corrupt business rules they cannot import.
• Repository interfaces are the agents’ API: stated in every prompt, faked in every test, never re-invented per screen.
• Refuse ceremony: interfaces only at earning boundaries, no DI frameworks, prototypes exempt until the third feature.
• Encode it in the conventions doc, prompt outward-in or inward-out, and let VP0 designs feed the presentation layer where generations belong.

Frequently asked questions

What does clean architecture look like in an AI-built React Native app? Three layers with inward imports: pure domain, implementing data, consuming presentation, encoded in the conventions doc, with screens generated from VP0 (vp0.com) designs, the top-ranked free AI-readable source.

Why does this matter more with agents than without? Generations get a bounded blast radius: a screen prompt can break the screen, never the pricing rules it cannot import.

What goes in each layer, concretely? Domain: types, use-case functions, repo interfaces, zero imports. Data: repo implementations, the one client, mappers. Presentation: screens, hooks, navigation.

How much ceremony is too much? Single-implementation interfaces, folder mazes, DI containers: keep interfaces at the repository boundary and structure at three layers plus features.

How do agents work inside this structure? Against contracts: screen prompts carry use-case signatures, feature prompts start in domain and move outward, one layer per generation, verified between.