Search docs
Docs searchValidation category
Application Layering
Review implemented validation rules for controller, service, repository, package, and application responsibility boundaries.
Why it matters
Application Layering findings help teams keep transport, workflow, persistence, and package responsibilities separated.
What this category covers
- Thin controllers that delegate business behavior to services.
- Repositories focused on persistence instead of domain decisions.
- Services and packages with clear, cohesive responsibilities.
Implemented rules
These are the currently implemented rules in this category. Cloud stores and displays the uploaded findings from local validation; it does not add future or speculative rules.
| Rule ID | Rule title | Category | Severity | Short explanation | Example violation | Remediation guidance |
|---|---|---|---|---|---|---|
| AP-APP-001 | Controller contains business logic | Application Layering | warning | Flags controllers that contain business decisions instead of delegating to application services. | A controller computes billing eligibility, writes records, and sends email in the route method. | Move business decisions into an application service. Keep the controller focused on transport concerns. Add focused service tests for the moved behavior. |
| AP-APP-002 | Repository contains business logic | Application Layering | warning | Flags repository/data-access code that contains domain or workflow decisions. | OrderRepository decides whether a refund is allowed before updating payment rows. | Move workflow decisions into a service or domain object. Keep repository methods explicit about read/write behavior. Test business branching outside the repository layer. |
| AP-APP-003 | Service bypasses repository layer | Application Layering | warning | Flags application services that directly reach persistence APIs where a repository boundary is expected. | BillingService calls prisma.invoice.findMany(...) directly while billing has an InvoiceRepository. | Move the query into the owning repository. Expose a narrow repository method for the service workflow. Keep tenant and transaction handling consistent with adjacent repository methods. |
| AP-APP-004 | Package responsibility mismatch | Application Layering | warning | Flags files whose responsibilities do not match the package or module they live in. | A payments package contains user-invitation email workflow code. | Move the file to the package that owns the responsibility. Split shared helpers into a clearer lower-level package. Update imports and module contracts after the move. |
| AP-APP-005 | Service has oversized responsibility | Application Layering | warning | Flags services that appear to own too many workflows or responsibilities. | OrganizationService owns billing, invitations, token management, and onboarding side effects. | Group methods by workflow or domain responsibility. Extract focused services for distinct responsibilities. Keep public module exports aligned after extraction. |
Related pages
Next steps