Une autre façon de structurer votre projet Symfony

L'architecture MVC + Services est si courante dans les projets Symfony qu'elle semble être la seule solution. C'est simple, familier et cela fonctionne... jusqu'à ce que ce ne soit plus le cas. À mesure que votre projet se développe, des fissures commencent à apparaître : votre logique métier est partout, le comportement des applications n'est pas clair et la maintenance du code devient pénible. Bien qu’il s’agisse de l’approche la plus courante, Symfony ne vous oblige pas à vous y tenir.

Et s'il y avait une meilleure solution ?

Les frustrations liées à l'utilisation de l'architecture de services MVC +

La logique de domaine est répandue partout

À mesure qu'un projet se développe, la logique métier a tendance à s'étendre à l'ensemble de la base de code. Chaque couche du projet (contrôleurs, services, formulaires, entités) finit par contenir des éléments du modèle de domaine. Cela rend de plus en plus difficile de se concentrer sur une partie spécifique.

Les limites du projet ne sont pas claires

Lorsque votre architecture est organisée autour de couches techniques, il devient plus difficile d'identifier des limites claires entre les différents contextes à mesure que le projet se développe. Ce manque de clarté peut entraîner des problèmes de code et de maintenance étroitement liés.

Les comportements du projet ne sont pas clairs

Étant donné que l'architecture par défaut met l'accent sur les couches techniques, il devient assez difficile de comprendre les comportements du projet. Vous pouvez déduire que certaines entités sont gérées par des services spécifiques ou deviner le schéma de la base de données, mais les comportements réels du projet, qui constituent les ...
[Courte citation de 8% de l'article original]