Application Layering

Overview

Review implemented validation rules for controller, service, repository, package, and application responsibility boundaries.

Application Layering findings help teams keep transport, workflow, persistence, and package responsibilities separated.

Why it matters

Cloud uses this guidance to help teams interpret local validation findings in organization context without turning the docs into implementation notes.

When this domain drifts, findings become harder to triage, ownership becomes less clear, and architecture review depends too much on individual memory.

Good architectural practices

• Thin controllers that delegate business behavior to services.
• Repositories focused on persistence instead of domain decisions.
• Services and packages with clear, cohesive responsibilities.

Common anti-patterns

• Controller contains business logic
• Repository contains business logic
• Service bypasses repository layer
• Package responsibility mismatch
• Service has oversized responsibility

Relationship to other architecture areas

This domain usually overlaps with neighboring validation categories. Use the related pages below to understand the adjacent architecture concerns before changing policy, suppressing a finding, or accepting risk.

Implemented rules

These are the currently implemented rules in this category. Use this table for category-level orientation, then open the Rule Catalog when you need rule-specific examples and remediation guidance.