Structurez votre code explicitement avec la "Screaming Architecture"

Vous est-il déjà arrivé d’ouvrir un projet, de regarder la structure de son code, l’organisation des différents répertoires et de n’avoir aucune information sur les fonctionnalités, les cas d’utilisation ou encore le métier géré par ce dernier ? En ce qui me concerne, c’est le cas de nombreux projets que j’ai pu voir, car bien souvent, la structure des projets est organisée par couches techniques orientées dont la structure dépendra généralement du framework utilisé. C’est exactement pour éviter de ce genre de déconvenues qu’est né le concept de Screaming Architecture.

La Screaming Architecture (que l’on pourrait traduire par l’Architecture Criante en français) est un principe d’architecture logicielle théorisé par Robert C. Martin (alias Uncle Bob) et qui stipule que la structure de code d’un projet devrait révéler clairement l’intention et la fonction d’un logiciel sans avoir à entrer dans les détails d’implémentation.

Or, bien souvent, lorsque l’on démarre un nouveau projet avec son framework préféré, nous utilisons le squelette par défaut proposé par ce dernier. Par exemple, la structure d’un projet Symfony se présente généralement sous la forme suivante:

src
├── Command
├── Controller
├── DataFixtures
├── Entity
├── Event
├── EventSubscriber
├── Form
├── Pagination
├── Repository
├── Security
├── Twig
├── Utils
└── Kernel.php

Il serait préférable de regrouper les différents éléments au sein de dossiers représentant des contextes métier et fonctionnels, ce qui permettra de rendre plus facile la compréhension globale d’une fonctionnalité en évitant de devoir naviguer dans el code pour comprendre ou modifier un comportement.

src
├── Authentication
├── Inventory
├── Order
├── Reporting
├── Shipping
├── User
└── Kernel.php

Libre à vous ensuite, de choisir le découpage de chacun des contextes. Vous pouvez utiliser une structure orientée Clean Architecture ou architecture hexagonale, mais aussi du Vertical Slice ou un découpage plus courant en CRUD ou RAD. Le choix pouvant être fait selon les besoins et la complexité de chacun des contextes.

Ce mode de fonctionnement possède de nombreux avantages:

• la structure révèle l’intention métier rendant l’organisation du projet plus expressive et facilitant la compréhension de ce dernier par un nouveau développeur,
• le code devient un peu plus indépendant du framework car vous organisez votre code en fonction de votre métier et non pas en fonction de la couche technique que vous utilisez,
• les détails d’implémentation sont relégués au second plan mettant en avant la logique métier.

Lorsque vous tentez de mettre en place une Screaming Architecture, le plus important est de commencer par vous focaliser sur les cas d’utilisation que vous allez résoudre. Séparez ces derniers autour de concepts métier sans réfléchir aux détails techniques.

La Screaming Architecture n’est pas seulement une façon d’organiser du code, c’est un philosophie qui place l’intention du logiciel au premier plan. Avec ce principe, créez des projets plus compréhensible et maintenable. Attention cependant à ne pas tomber dans l’over engineering, ne multipliez pas les couches ou classes. Trouvez le bon équilibre entre principe de base et pragmatisme, c’est le secret de tous les projets qui durent.