Naar de inhoud
Recognized by Laravel Match je project Contact
Projectstructuur en architectuur

Houd de standaard mappenstructuur aan

Voor het laatst bijgewerkt op:

Introductie

Laravel heeft een standaard mappenstructuur. De structuur kan naar wens worden aangepast, maar het is over het algemeen niet aan te raden om hier te veel van af te wijken.

Waarom

  • Door niet te veel af te wijken van de standaard mappenstructuur blijft je project overzichtelijk en herkenbaar. Dit betaalt zich uit bij het uitvoeren van Laravel-upgrades en bij het onboarden en samenwerken met andere developers.
  • Je hoeft het wiel niet opnieuw uit te vinden. De mappenstructuur is een bewuste indeling, waardoor je minder keuzes hoeft te maken over waar je bepaalde zaken plaatst. Dit bespaart tijd en zorgt ervoor dat nieuwe functionaliteiten sneller ontwikkeld kunnen worden.
  • Je project is beter compatibel met packages. Doordat alles staat waar het hoort, kom je minder fouten tegen.

Geschikt voor

  • Kleine tot middelgrote projecten

Minder geschikt voor

  • Grote projecten. Voor grote projecten kan het nuttig zijn om met modules te werken.

Meer informatie

Skill

Laravel Boost Skill

Gebruik deze skill om de richtlijn rechtstreeks toe te passen met een AI-assistent.

Use this skill when a Laravel task touches this best practice. It is self-contained so it can be installed independently by Laravel Boost or another agent-skill system.

## Core Guidance

Laravel has a standard folder structure. The structure can be adjusted as desired, but it is generally not recommended to deviate too much from this.

## Why It Matters

- By not deviating too much from the standard folder structure, your project remains clear and recognizable. This pays off when implementing Laravel upgrades and onboarding and collaborating with other developers.
- You don't have to reinvent the wheel. The folder structure is a conscious division, so you have to make fewer choices about where to place certain things. This saves time and allows new functionalities to be developed faster.
- Your project is more compatible with packages. Because everything is where it belongs, you will encounter fewer errors.

## Apply When

- Small to medium projects

## Be Careful When

- Major projects. For large projects it can be useful to work with modules.

## Canonical Source

- Full best practice: https://github.com/Dutch-Laravel-Foundation/best-practices/blob/main/project-structure-and-code-architecture/keep-the-standard-folder-structure/BEST_PRACTICE.md
- Dutch translation: https://github.com/Dutch-Laravel-Foundation/best-practices/blob/main/project-structure-and-code-architecture/keep-the-standard-folder-structure/translations/nl.md

## Workflow

1. Inspect the user's Laravel code before recommending changes.
2. Identify the narrow rule from this best practice that applies to the task.
3. Prefer Laravel's built-in conventions and documented APIs over custom abstractions.
4. Keep examples focused on this practice; reference other skills or practices when the task crosses boundaries.
5. Verify code changes with the project's available tests, linters, static analysis, or framework checks.

## Review Checklist

- The recommendation is Laravel-specific and grounded in this practice.
- Code examples use realistic Laravel file names, class names, and method names.
- The advice avoids mixing unrelated architecture, deployment, security, or testing topics.
- Related practices are mentioned when useful, but not re-explained in full.
- Dutch output, when requested, keeps framework and API names intact.