Salut et bienvenue dans ce nouvel épisode du podcast de Code Garage,
je m'appelle Nicolas Brondin-Bernard et aujourd'hui on va parler d'un concept
d'une architecture qui s'appelle la Screaming Architecture. Alors en développement logiciel,
on parle souvent de performance, de framework, de bonne pratique, etc. Mais en fait on parle
assez rarement, alors de plus en plus maintenant, mais de lisibilité métier. En fait c'est justement
ça que propose la Screaming Architecture. Screaming Architecture, ça veut dire Screaming,
c'est crier en anglais. Et donc c'est une manière de structurer son code pour qu'il crie ce que fait
l'application littéralement, alors pas littéralement évidemment puisque votre code ne va pas crier.
Mais en fait, l'idée derrière ça, c'est qu'en regardant les dossiers et les fichiers d'un
de vos projets, eh bien qu'on puisse comprendre immédiatement dans quel domaine de métier on
se trouve. C'est un concept qui a été popularisé par Robert T. Martin, l'oncle Bob, alors qu'il
a un personnage qui est très controversé, donc on va pas s'arrêter, on va pas s'étendre plus sur ça,
mais ça fait, c'est aussi un des piliers un petit peu de la clean architecture qu'il a introduit aussi.
Alors maintenant on va prendre un exemple pour que ce soit un petit peu plus parlant. On va dire
que c'est un projet front-end mais très honnêtement, c'est pas très important. Donc à la racine de notre
projet, on va avoir des dossiers comme components, pages, services, models, utiles, etc. Alors cette
structure, elle est évidemment bien rangée, mais elle dit absolument rien du domaine que va
couvrir l'application. Est-ce que c'est, je sais pas, un réseau social, une appli de gestion de
stock, un outil médical ou pour la mutuelle, les assurances, peu importe. On ne peut pas le savoir
juste en regardant ça. Le code, il est centré plutôt sur la technique et pas sur ce qu'il essaye de
résoudre dans la vraie vie. Alors qu'est-ce que ça donnerait ça du coup avec la scrimine
architecture ? On va prendre par exemple, je sais pas, une application pour gérer une école de
musique, et bien au lieu d'avoir les dossiers que j'ai cités précédemment, on va plutôt avoir
des dossiers qui vont être students, teachers, lessons, enrollments, chats, etc. Chats, c'est plutôt
pour tout le code qui va être partagé entre tout le reste. En tout cas là, on a pu besoin d'ouvrir
le code, d'ouvrir les dossiers pour deviner ce que va faire l'application. On comprend immédiatement
que l'appli est gère des élèves, des professeurs, des cours et des inscriptions. Alors évidemment là,
vous allez pouvoir me dire, on sait pas que c'est une école de musique spécifiquement, mais une école
de musique, ça se gère comme n'importe quelle école. Donc là en tout cas, si on prend ça,
eh bien les codes y crient réellement ce qu'ils font puisqu'on devine en un clin d'œil. Et c'est ça
l'essence de la scrimine architecture. Alors pourquoi est-ce que ça, c'est important ou intéressant ?
En fait, structurer son code justement autour du métier plutôt que de la technique, ça va
présenter plusieurs avantages. D'abord, on l'a dit, la lisibilité, parce que quand un nouveau
développeur, une nouvelle développeuse arrive sur le projet, eh bien ils comprennent très rapidement
l'objectif un petit peu de chaque partie du code. Ça permet une meilleure collaboration avec des
gens qui seraient moins techniques, parce que les termes utilisés sont ceux du métier,
pas simplement du jargon de développeur. Et il y a quand même, alors le but en tout cas,
c'est qu'il y ait moins de dépendance aux outils. Le jour où vous changez de framework,
ou de base de données, ou peu importe, et bien en fait l'organisation métier est censée rester
la même. Alors ça favorise surtout une architecture orientée domaines, comme on peut avoir
justement dans la clin architecture, comme on l'a dit au début, ou même c'est ce qui est
prené aussi par le domaine driven design, le DDD. Mais voilà, on va pas s'attarder là-dessus,
parce qu'il faudrait bien plus d'un épisode de blog pour vous expliquer tout ça. Alors est-ce
que c'est une recette magique ? Ben non en fait, comme toute approche, comme toute architecture,
ça, la scrimine architecture, elle a ses limites, ses critiques. Il y a des gens qui militent évidemment
au effort pour que ce soit implémenté partout, et il y en a qui ne peuvent pas le voir. Et évidemment,
il y a un entre-deux qui est en général, là on va essayer de se situer. Alors moi je vais vous
lister quelques-uns, quelques-unes des limites, on va dire, ou des inconvénients que ça peut apporter.
D'abord, sur une application à vraiment grande échelle, quand on va avoir beaucoup de
fonctionnalités qui ne vont pas simplement être liées au métier, mais bel et bien à la technique,
ça peut être l'authentification, les erreurs, les logs, des calculs, l'ontougeant, peu importe,
ben en fait quand il y a beaucoup de ces fonctionnalités-là qui sont transversales à tous les domaines,
quand on va structurer uniquement par dossier métier, ça peut devenir un peu confus,
ou ça peut, on va avoir tendance à créer du code redondant. Évidemment, ça c'est un peu le
revers de la médaille encore, je sais pas si ça en est vraiment, mais c'est que ça exige une bonne
compréhension du métier. Alors ça pour le coup, si jamais c'est un métier extrêmement complexe,
et bien ça peut être un peu plus dur de rentrer dedans, parce que si vous ne connaissez pas
parfaitement le métier, ce qui est très souvent le cas quand vous arrivez sur un nouveau projet,
ou un nouveau poste, ça va être encore plus dur de rentrer dans le projet, mais surtout si
jamais l'équipe n'a pas une vision claire du domaine en général, et bien forcer justement cette
structure où on va d'abord se concentrer sur le métier, ça peut nuire un petit peu à la cohérence
du projet ou parfois à la compréhension de l'équipe. Là on parle vraiment quand c'est des domaines
assez précis, assez complexes. Quand on a des équipes très techniques structurées vraiment
par rôle, quand on va avoir quelqu'un pour le frontaine, quelqu'un pour le back end, quelqu'un
pour le mobile par exemple, quelqu'un pour la base donnée, etc. Et bien organiser tout par domaine,
ça peut un petit peu aller à l'encontre de la logique de travail de tout le monde, selon comment
c'est organisé. Si on est sur un monolithe, si on est sur des microservice, si on est sur plein de
choses différentes, en fait la manière d'organiser le projet, ça peut amener quelques confusions.
Et surtout, moi ce que je trouve important c'est que parfois ça peut masquer des enjeux techniques
qui peuvent être cruciaux. Par exemple on a certains projets, on va avoir je ne sais pas du temps
réel, de la sécurité très renforcée, de l'IA, des choses comme ça. Et bien en fait ces choix
techniques et ces contraintes techniques, elles sont parfois réellement au coeur du projet. Donc ça
peut être vraiment utile de les rendre visibles dans la structure puisque tout notre application
va tourner autour de ça plus qu'autour du métier. Maintenant évidemment, là je vous ai fait une
petite liste des limites et des critiques que vous pouvez entendre régulièrement sur cette
architecture. Maintenant je pense quand même que ce sont des limites qui sont à la marge,
mais il faut quand même en avoir conscience. Alors pareil, on a fait un épisode sur le cargo culte,
le culte du cargo que je vous inviterai évidemment à aller écouter. Je vous mettrai
le lien directement dans les notes de cet épisode. Mais là, ce crime en architecture,
c'est pas une règle rigide, c'est un principe de bon sens on peut dire. Le code devrait refléter
ce qu'on est en train de construire, mais évidemment il y a plein de cas où une architecture hybride
va être plus efficace. Ça va être par exemple des dossiers métier, donc studence, course,
enrollment, etc pour les entités centrales. Et ensuite à l'intérieur de ces entités centrales,
on va pouvoir rediviser un concept un petit peu plus technique dans des sous-dossiers. On peut quand
même retrouver un petit peu le meilleur des deux mondes avec des architectures un petit peu
hybrides comme ça. Donc en résumé, l'idée de la scrimmine architecture, c'est vraiment très simple,
c'est votre code devrait parler métier et pas techno d'abord. Ça permet de mieux communiquer
et surtout de rester centré sur l'essentiel, résoudre un vrai problème pour un vrai utilisateur.
J'espère que cet épisode vous aura plu, qui vous aura appris quelque chose. Pensez à laisser
cinq étoiles dès que vous finissez d'écouter cet épisode même si vous êtes en voiture,
bien évidemment attendez d'être un fer rouge, ne le faites pas au volant, mais en tout cas ça
aide vraiment le référencement et à progresser justement dans le classement sur Spotify, Apple
Podcast, Deezer, etc. et donc de gagner en visibilité et de soutenir notre travail.
Moi je vous donne rendez-vous la semaine prochaine pour un prochain épisode de podcast et évidemment
tous les jours sur code-garage.fr pour retrouver tous nos articles de blog, tous nos épisodes
de podcast et tous nos cours complets. Il y a une grosse gamme de cours gratuits, il y a une gamme
de cours payant aussi pour aller vraiment en profondeur et construire une expertise autour de
certaines techno. Venez faire un tour et moi je vous retrouve la semaine prochaine. Prenez soin de vous. Salut !