laravel-audit-architecture

Laravel Architecture Audit

Audit the architecture of the Laravel application. Avoid cargo-cult recommendations such as "create a repository for every model" or "move everything into services."

List applicable rules first:

php artisan auditor:rules --domain=architecture --applicable

What to look for

• Clear violations of application boundaries: domain logic leaking into controllers, routes, or views; persistence concerns in presentation layers.
• Duplicated business logic: the same rule implemented in several places with divergence risk.
• Excessive controller responsibility: controllers doing far more than orchestrating HTTP.
• Business logic in inappropriate layers: rules embedded in views, middleware, or migrations.
• Tightly coupled components: classes that are hard to test or change because of hidden dependencies.
• Repeated patterns that have become maintenance problems: copy-pasted blocks that should be shared.
• Inconsistent architectural conventions: half the app using one pattern and half another without reason.
• Unnecessary abstractions: interfaces, repositories, or services that add indirection without value.
• Dangerous service/repository patterns: abstraction layers that create complexity rather than value.

Evidence requirements

Every architecture finding needs at least:

• The specific class(es) and file/line ranges.
• Why the pattern is a problem in this codebase (not just "best practice").
• A concrete improvement that fits the existing style.

False positives

• Small controllers that orchestrate a couple of calls are fine.
• A service layer is not automatically bad; only flag it when it adds complexity without value.
• Do not impose a single architecture style the codebase does not otherwise use.

Severity guidance

• high: structure actively blocks maintenance or causes bugs (e.g. duplicated critical logic diverging).
• medium: clear maintainability problem with real cost.
• low: stylistic or mild structure concern.
• info: observations for future work.