On this page
Application Structure
A RAD application is easiest to maintain when each layer has one clear responsibility.
| Area | Responsibility |
|---|---|
| Public surface | Entry points and reviewed browser assets |
| Microservicelets | Feature routes and feature-scoped behavior |
| Application classes | Reusable domain, policy, and persistence operations |
| Themes | Shared page shells and presentation structure |
| Configuration | Environment-specific settings kept outside public access |
| Runtime data | Private files, cache, temporary artifacts, and logs |
Feature Boundary
Group a coherent feature in one microservicelet. Keep request loading in the route controller, document rendering in the pagepart, route-specific styles in the prepart, and route-specific browser behavior in the postpart.
Avoid putting credentials, private downloads, database exports, debug traces, or runtime configuration beneath a public asset path. Files that require authorization should be delivered by permission-checked handlers.
Maintainability Check
A reviewer should be able to identify the request boundary, authorization decision, business operation, persistence operation, and rendered output without tracing unrelated features.