Une recette native

J’enfonce peut-être une porte ouverte, mais ça me semble important à expliciter. Plutôt que de se lancer directement dans la création des pont tout en intégration les SDKs, on a décidé de commencer par tester simplement les SDKs en créant des applications natives.

Un nouveau projet sur iOS et un nouveau pour Android donc, qui importent chacun le SDK correspondant. Rien de plus. Deux raisons à cela.

Premièrement, on n’était pas sachant sur la création du pont, c’était la première fois qu’on devait le faire. On voulait éviter d’apprendre deux choses en même temps (le fonctionnement d’un pont, le fonctionnement du SDK). Là, on reste focus sur une seule chose et on avance par petites étapes.

Deuxièmement, on voulait restreindre le nombre de problèmes au minimum. Lorsque ça ne marchait pas, ça pouvait venir soit de notre code natif, contenant d’ailleurs peu de lignes, soit du SDK. On s’est enlevé de nombreux doutes. “Est-ce que ça déconne à cause du code Flutter ? De notre façon de faire le pont ? Ou alors de notre code natif ? Ou du SDK ? Ou peut-être bien de notre projet ?”. Non, tout ce bruit, on veut l’éviter.

Et on a bien fait. On a pu repérer des problèmes provenant de notre partenaire. Même si on a d’abord douté de notre façon d’utiliser le SDK, on a rapidement éliminé ces pistes au vu du peu de lignes de code que l’on avait dans nos applications créées pour l’occasion.

Un pont Flutter <> Natif

Vient maintenant de la recherche pour créer ce fameux pont entre du code Flutter et du code natif. Toujours dans de nouvelles applications, ET sans utiliser les SDKs pour le moment. Mêmes raisons qu’au-dessus, on voulait se concentrer sur une chose à la fois et diminuer les sources d’erreurs.

On a fouillé les internets, et on a débusqué plusieurs options pour faire discuter ensemble Flutter et le natif :

• Platform channels
• dart:ffi (Android et iOS)
• Pigeon

Notre préférence est allée vers les Platform channels, qui nous semblaient plus adaptés à notre besoin et assez simple d’usage.

Intégration du SDK dans le projet

Le temps d’intégrer les SDKs natifs directement dans notre application Flutter est ensuite arrivé. Nous étions serein avec nos expérimentations et apprentissages.

Pour donner un peu de contexte (simplifié), on devait intégrer un SDK de messagerie. Disons qu’il permet d’identifier un utilisateur via son token, d’ouvrir un salon de discussion, d’envoyer un message et de voir les nouveaux messages arriver.

On a utilisé un MethodChannel et un EventChannel. Le premier nous sert de donneur d’ordres, il contrôle le SDK depuis notre code Flutter. Le second nous permet de faire transiter des flux de données du SDK vers Flutter - les messages du chat.

On a un repository qui cache la complexité du SDK. Les deux channels ne se connaissent pas, ils ne parlent qu’à l’instance de ce repository.

Tout fonctionne bien, on avance rapidement. Mais je commence à écrire un morceau de code côté iOS qui ne me plaît pas.

Pour voir les nouveaux messages arriver, il faut ouvrir un salon de discussion. Et pour ouvrir un salon, il faut être connecté. Ce séquencement, je l’écris en swift, donc nativement sur iOS. De base, ce qui m’intéresse fonctionnellement, c’est de voir les messages. Le reste doit être transparent pour l’utilisateur. Je n’expose à Flutter qu’un simple démarrer l'écoute des messages.

Tous ces appels de fonctions sont bien entendus asynchrones. Je target iOS 11, donc pas de async/await. Je ne vais pas ajouter RxSwift, PromiseKit ou une autre librairie juste pour ça non plus. Je vous laisse imaginer la cascade de closure qui se forme. J’essaie d’éclater en plusieurs fonctions, mais ce n’est pas idéal.

Ah, et chaque appel peut échouer. Donc il faut gérer des erreurs à chaque niveau. Ok mais on passe pars un seul et même callback pour répondre à Flutter, comment je fais pour différencier les erreurs ? Est-ce que même j’ai envie de différencier ?

Vers un passe-plat

C’est à ce moment que je me dis “et si on déportait tout ça vers Flutter ?”, “et si on ne faisait qu’un passe-plat ?”. Mais oui. Tout simplement.

Notre pont ne sert plus que d’interface pour parler au natif. Il fait passe-plat. Côté natif, on expose les fonctions dont a besoin uniquement et telle quelle, rien d’autres. Côté Flutter, on orchestre, on a de la logique.

Ce que j’aime bien avec cette solution, c’est qu’on tend vers du zéro logique côté natif.

On écrit moins de code en doublon (Android et iOS). Ce qui est quand même une des raisons d’être d’une application en Flutter, autant continuer en ce sens. S’il y a une modification de la logique, on ne le fera qu’à un seul endroit - côté Flutter.

On profite de la modernité de Dart et des packages que l’on a ajouté à notre projet pour développer la logique. J’ai par exemple pu jouer avec le async/await proposé naturellement par le langage Dart.

On capitalise sur l’expertise Flutter des développeurs. Certain n’ont jamais développé sur Android ou iOS, voire aucun des deux. Pour autant, ils maîtrisent Dart et l’écosystème de Flutter.

Et c’est enfin à ce moment-là que je me dis “et si j’écrivais un article ?”. La boucle est bouclée.

De base, notre backend stocke des données, communique avec d’autres services et applique de nombreuses règles métiers. Notre application, elle, va envoyer une requête pour récupérer des informations, les traiter, appliquer d’autres règles, puis construire un rendu visuel avec divers composants UI (j’ai une bannière, ensuite un carrousel avec trois images, puis une liste d’articles).

On a vu qu’on pouvait ajouter des traitements spécifiques au mobile en ayant un Back for Frontend. Ça nous aide en déportant certaines règles côté backend, en agrégeant des données de plusieurs sources, en facilitant certains changements. Reste encore à construire le rendu visuel côté application.

On en arrive au cran d’après. Bienvenue dans le Server-Driven UI.

Je te dis comment afficher

Avec du Server-Driven UI (aussi appelé Server-Driven Rendering, Backend-Driven UI, …), il y a un backend qui va à la fois retourner des données ET indiquer comment les présenter. Une partie de la construction de l’interface graphique (du front mobile) est déportée côté backend.

Qu’est-ce que ça veut dire, construire l’interface ? Eh bien, le backend indique les composants à afficher (une bannière, un carrousel, une liste d’éléments, une image, …) directement renseignés avec les données associées. De fait, la composition de l’écran est aussi gérée (j’ai d’abord la bannière, ensuite le carrousel, …). Et il pourrait aussi configurer les composants (le texte de la carte est bleu, la police de 16pt, …), les actions lorsque l’on tape sur un élément.

La réponse à une requête sera beaucoup plus riche. Un exemple au format JSON :

{
    "title": "Accueil",
    "content": [
        {
            "type": "carousel",
            "content": [
                {
                    "image": "https://monserveur.com/img/001.jpg",
                    "text": "Arthur",
                    "color": "#FFFFFF"
                },
                {
                    "image": "https://monserveur.com/img/002.jpg",
                    "text": "Perceval",
                    "color": "#FFFFFF"
                },
                {
                    "image": "https://monserveur.com/img/003.jpg",
                    "text": "Lancelot",
                    "color": "#FFFFFF"
                }
            ]
        },
        {
            "identifier": "list",
            "content": [
                {
                    "title": "Les personnages",
                    "description": "En découvrir plus sur les personnages",
                    "details": "88026897-3fcb-4de8-af77-9aeb76d1e8a1"
                },
                {
                    "title": "Les secrets de tournage",
                    "description": "Mystère et magie !",
                    "details": "1da6005c-1f57-4c95-bb1a-6fb3b3a1bde7"
                }
            ]
        }
    ]
}

On obtient donc un nouveau moyen de mettre à jour une application mobile sans passer par les stores. On peut contrôler la construction de l’affichage à distance. Ça nous intéresse car ça nous ouvre des portes pour expérimenter, pour changer plus vite.

Tout cela implique un développement côté serveur et côté application.

• Côté serveur. Il y a une brique / un service / un backend qui construit cette réponse plus complexe. Qui doit avoir cette logique de présentation des données.
• Côté application mobile. Il faut créer chaque composant et il faut une brique qui interprète la réponse du serveur pour la traduire dans les composants correspondants.

Et vu que c’est à notre portée, on peut aller aussi loin que nécessaire pour répondre à notre besoin. On peut avoir une présentation plutôt simple. Le serveur indiquerait seulement des composants à afficher avec leurs données. Ou au contraire, on peut pousser la configuration en détaillant des tailles de texte, des couleurs, des alignements, etc.

On a également le choix d’appliquer ce concept dans les parties de l’application qui nous intéressent. On peut avoir du Server-Driven UI uniquement sur une sous-partie de l’application. Ce n’est pas structurant au point de nécessiter d’en avoir partout. Mais on peut le faire, s’il y a le besoin. On adapte !

Quelques cas - exemples

Pour illustrer et donner de l’inspiration, voici des cas qui existent en production sur des applications grand public.

Une campagne de satisfaction. Sous la forme d’un simple formulaire, avec une suite de questions et plusieurs formats de réponses (choix multiple, choix unique, champs de texte libre). La complexité technique et fonctionnelle est faible. Il ne s’agit que de donner des questions et d’indiquer sous quelle forme on peut y répondre. Il y a un besoin de déclencher une campagne à n’importe quel moment et de moduler le contenu.

Un quizz. On est dans le même ordre d’idées, c’est au final une sorte de formulaire mais présenté sous une autre forme. Ici, le besoin est d’avoir un parcours de questions qui change régulièrement, sans pour autant faire de mise à jour.

Un onboarding. On entre dans un parcours bien plus complexe et lourd. C’est une succession d’écrans avec de nombreuses possibilités comme des formulaires, des listes, des présentation de CGU, de l’upload de fichier, de la visualisation d’images, etc. Les formulaires sont complexes, contiennent des règles de validation, possèdent plusieurs formes (champs libres, choix multiple, champs numéro de téléphone, …). On peut ajouter des boutons et des popups d’aide / assistance. Bref, un parcours complètement modulable car il y a un fort besoin de changement. À l’autre bout, un back-office existe pour configurer tout cela.

Une page d’accueil. Pas de parcours mais une composition de page qui nécessite d’être très modulable. Un jour une simple liste, un autre jour une mise en avant avec une bannière et un el suivi de la liste. Parfois des raccourcis, des cartes d’action rapide. D’autres fois des rappels. Et demain, un peu de tout ça en même temps. D’ailleurs, on expérimente facilement ce qui marche le mieux en changeant à distance l’interface.

Un fil de contenu. Dès lors que le contenu est très dynamique, sa présentation l’est aussi. On a besoin d’adapter les formats.

Bénéfices

Outre la gestion de l’affichage déporté sur un serveur, on peut espérer obtenir d’autres avantages grâce au Server-Driven UI.

Déjà, et c’est ce qui nous intéressait le plus par rapport à notre histoire, à cette série d’articles, on peut changer de nouveaux éléments de notre application mobile sans devoir passer par les stores : l’interface graphique.

Et on est plutôt ravi de cette possibilité. On va pouvoir changer à distance plus profondément l’application, on va pouvoir apporter des changements et des corrections plus rapidement aux utilisateurs. On aura plus de contrôle.

On facilite également l’expérimentation, l’A/B Testing. Pas besoin de Feature Flag, c’est un serveur qui génère la composition de l’écran. C’est déjà de la configuration à distance. On peut donc dès maintenant expérimenter.

Si plusieurs plateformes consomment notre serveur, on gagne une unification des interfaces. Le serveur devient une source de vérité unique, les applications clientes ne feront qu’appliquer la présentation reçue. On a plus facilement une cohérence entre différentes plateformes. Le changement de l’affichage ne se fera qu’à un seul endroit.

Points d’attention

Comme d’habitude, rien n’est magique ou parfait. Le Server-Driven UI ne fait pas exception.

Je commence par enfoncer une porte ouverte. Si on veut que notre serveur retourne un nouveau composant, ou une nouvelle configuration par exemple, il faut le code de notre application puisse l’interpréter. Il faut donc soumettre une mise à jour de l’application pour gérer ces nouveaux cas. Comme si on ajoutait une nouvelle Feature Flag.

Je continue avec une autre porte voisine, les versions. Il faut garder en tête que dans la nature, il y a possiblement une grande variété de versions de notre application. Eh oui, pour rappel, rien n’oblige un utilisateur à mettre à jour une application mobile. Il la fera peut-être rapidement, ou dans une semaine, ou jamais.

On a donc une problématique de rétrocompatibilité. Admettons qu’on ajoute un nouveau composant et qu’on ait une nouvelle version de l’application qui le gère, comment ça se passe pour les anciennes applications ? On peut versionner nos composants. On peut créer un mécanisme de mise à jour forcée. On peut ignorer. On a plusieurs options, mais il faut y penser.

Le Server-Driven UI, c’est également une couche supplémentaire dans notre système. Ça vient avec son lot de complexité, de besoin de maintenance, de debug, etc. Et ça requiert un investissement à l’entrée. Il y a un coût de développement plus élevé au début pour mettre en place les différentes briques et composants pour que tout fonctionne.

Je pense aussi à la sécurité. La surface d’attaque de l’application est augmentée puisqu’elle se base davantage sur des instructions extérieures. Il est facile de modifier à la volée une réponse HTTP. Par exemple, si le serveur indique des intentions de navigation ou d’action, l’application devrait peut-être vérifier que l’utilisateur a bien le droit de le faire.

Pour se lancer

Le sujet du Server-Driven UI étant vaste et complexe, on peut chercher à en apprendre plus en s’inspirant de retours d’expériences de grands noms qui en font ou qui en ont fait de manière poussée : AirBnb, Instagram, Lyft, Reddit, Square.

On peut aussi regarder du côté de frameworks qui existent déjà. En faisant une rapide recherche, je tombe sur DivKit et beagle qui proposent des solutions à la fois côté serveur et côté client iOS, Android, web. J’avais également repéré rfw (Remote Flutter Widget), mais qui me semble d’ailleurs plus proche d’un interpréteur de code. On le verra peut-être dans l’épisode suivant !

Série d’articles Mettre à jour une application mobile sans passer par les stores :

• #1 Pourquoi
• #2 Remote config, Feature F & co
• #3 Backend for Frontend (BFF)
• #4 Server-Driven UI
• #5 Interpréteur de code
• #6 Over-the-air update (OTA)
• #7 Les ressources
• #8 En résumé, mes options

Hors-série :

• Accélérer le temps de review App Store d’une application iOS
• Forcer la mise à jour d’une application mobile

J’ai fait le test avec mon téléphone, j’ai eu du mal à trouver une application qui ne faisait aucune requête (en tout cas en apparence, je n’en suis même pas sûr à 100%). J’ai la calculatrice qui vit sa vie dans son coin.

Pourquoi je raconte ça ? Parce que ces applications font très probablement des requêtes vers un serveur qui leur appartient. En d’autres termes, l’équipe, le département, ou l’entreprise qui gère le développement de l’application est également responsable du serveur.

Dans l’épisode précédent, on a vu qu’une configuration à distance permettait de changer le comportement d’une application mobile. Et que la configuration à distance, ce pouvait être simplement un fichier JSON ou une API qui exposait quelques valeurs.

De là à faire le rapprochement entre les données envoyées par nos serveurs et la possibilité de changer le comportement d’une application mobile à distance, il n’y a vraiment qu’un petit pas. Alors faisons-le !

Vers une API spécialisée

En général, ce qu’on retrouve souvent, c’est un backend qui tends vers de l’envoi de données brutes aux fronts. Et qui s’approche plus ou moins du REST. Pour alimenter une page, le front mobile devra effectuer une ou plusieurs requêtes puis traiter les données, appliquer un peu de logique.

Imaginons une page agenda sur notre application. On a envie de mettre en valeur les événements qui ont lieu aujourd’hui, dans de jolis encarts avec un maximum d’informations, ainsi que les 3 prochains événements. Pour le reste, on les groupe par semaine glissante et juste le titre nous suffira.

Notre backend nous propose une route qui retourne 100 événements, à partir du début de la semaine. Côté front mobile, on va devoir trier par date, filtrer les événements passés, mettre de côté les événements du jour et également les 3 prochains pour la mise en valeur, puis ensuite faire des groupes par semaine glissante.

Beaucoup de logique métier qui se retrouve côté client (l’application). Si on décide de changer, disons par exemple la sélection des événements qui sont mis en valeur, il faut modifier l’application et donc redéployer, ce qui implique de traverser tout le process de soumission sur les stores que l’on aimerait éviter.

Sans parler des données qui transitent sur le réseau : on a besoin que du titre pour une grande partie des événements. On augmente au passage la charge serveur pour rien. Bonne nouvelle, on a dit qu’on est responsable du serveur - on peut décider d’y déporter certaines logiques.

Le backend pourrait :

• Trier dans l’ordre adapté,
• Ne renvoyer que les futurs événements.
• Porter la mise en valeur en envoyant deux listes distinctes, et indiquer juste le titre pour les événements lointains.
• Grouper par semaine glissante.
• Aller plus loin en portant la logique de présentation. “Afficher une carte avec un titre, une description, une date pour cet événement mis en valeur, afficher un simple titre pour cet événement, etc”. On commencerait alors à parler de Server-Driven UI.

En fonction de ce que l’on déporte sur le backend, on pourra modifier le comportement de l’application à distance en déployant une nouvelle version du backend plutôt que de l’application. Et c’est souvent bien plus rapide.

Notre API, qui était généraliste, devient spécialisée pour un front.

Le cas GraphQL

Un petit aparté sur GraphQL. Je le mettrais bien dans le panier API généraliste pour notre histoire. Oui, ça apporte une certaine flexibilité au front qui consomme l’API, il peut sélectionner ce qu’il veut, mais à la fin, c’est toujours le front qui construit les requêtes. On veut finalement filtrer les événements passés ? Eh bien il faut redéployer l’application.

Certes, c’est une modification très simple puisque c’est peut-être seulement un paramètre dans la requête GraphQL à ajouter ou modifier, mais cette modification est à faire côté client (notre application). Elle impliquera une soumission de la version sur les stores.

On n’est pas dans la spécialisation de notre API, elle ne porte pas de la logique supplémentaire dédiée au front.

Backend for Frontend

Avoir une API spécialisée, ça peut nous embêter dans certains cas. Si j’ai plusieurs fronts par exemple : un site web et une application mobile. Il y a parfois une logique différente entre les deux. Le web est une autre plateforme, l’interface est très différente. Pour l’agenda, je veux tout afficher sous la forme d’un calendrier mensuel.

On comprend donc l’intérêt d’avoir une API généraliste qui essaye de faire plaisir à tout le monde. Pour autant, on perçoit aussi les avantages d’avoir une API spécialisée. C’est là qu’intervient le principe de Backend for Frontend : on peut avoir les deux !

Un Backend For Frontend, souvent connu avec l’acronyme BFF, est une couche intermédiaire entre un backend et un frontend. Concrètement, c’est un backend supplémentaire qui va traiter des données spécifiquement pour un type de front (une application mobile par exemple).

Notre front mobile va effectuer toutes ses requêtes en passant par le Back for Front, et uniquement ce dernier. C’est le Back for Front qui appellera le backend pour obtenir les données nécessaires. Il pourra ensuite appliquer de la logique dédiée avant de renvoyer les données à l’application mobile. Le site web aurait de son côté son propre Back for Front.

Vu que le Back for Front devient le point d’entrée unique du front, il peut servir d’agrégateur. Peut-être que pour notre agenda, on avait besoin de la liste des événements futurs et également des événements où l’on est inscrit. Plutôt que de faire deux requêtes, le front n’en fera qu’une seule vers le BFF.

Avec cette mécanique, on voit rapidement plusieurs avantages :

• On sépare les logiques spécialisées. Il y a un BFF mobile, un BFF web, etc.
• On sépare la partie spécialisée de la partie généraliste. Il y a un backend qui ne subit pas les caprices du front.
• Un développeur mobile peut plus aisément sortir de son éco-système et effectuer des changements sur le BFF.
• On peut regrouper plusieurs ressources en une seule route, et réfléchir en termes de page, d’écran.
• On cache la complexité au front. Il n’y a pas à savoir s’il y a plusieurs services ou même s’il y a un partenaire externe.

Et notamment, ce qui nous intéresse particulièrement dans cette série d’articles, on déporte de la logique client (app mobile) sur un serveur distant (notre BFF). On peut donc modifier du comportement sans passer par les stores ! On aime :)

C’est tout de même une décision à peser dans l’équipe. Qui dit couche supplémentaire, dit une maintenance supplémentaire. Il y a une nouvelle brique qui doit évoluer et être déployée. Déléguer davantage au Back for Front augmente au passage les possibilités d’erreurs sur l’application - elle est plus permissive. On songera à monitorer plus en profondeur ce qu’il se passe dans l’application.

Série d’articles Mettre à jour une application mobile sans passer par les stores :

• #1 Pourquoi
• #2 Remote config, Feature Flag & co
• #3 Backend for Frontend (BFF)
• #4 Server-Driven UI
• #5 Interpréteur de code
• #6 Over-the-air update (OTA)
• #7 Les ressources
• #8 En résumé, mes options

Hors-série :

• Accélérer le temps de review App Store d’une application iOS
• Forcer la mise à jour d’une application mobile

J’observe un nombre grandissant de discussions autour de la Clean Architecture. C’est davantage présent dans les projets, dans les souhaits, dans les échanges, dans les publications. Pourtant, je pense qu’une (trop grande) partie des personnes passe à côté de concepts essentiels et ne se pose pas les bonnes questions. Malgré la bonne intention, ça peut être dangereux. J’aimerais amorcer une prise de recul et ouvrir des questions.

Et si on prenait du recul ?

Je vois des discussions qui tournent seulement autour du pattern, du diagramme de classe. “Le Presenter fait ceci et cela. Il parle à celui-ci ou à celui-là.” Quand je demande ce qu’est la Clean Architecture, on me répond souvent en me récitant un diagramme de classe. Pas un mot sur l’abstraction, l’entrée/sortie, l’inversion de contrôle, … Et encore moins sur l’isolation du métier.

J’ai également assisté à des entretiens et des échanges avec des développeurs qui s’acharnent avec des suites de questions pour savoir si Machin va plutôt dans le Router ou Interactor ou Presenter, si c’est pas à Bidule de faire ça, et le rôle de Truc là-dedans, … Plutôt que de parler de l’esprit de la Clean Architecture, ils ne parlent que des classes.

Certaines équipes utilisent la Clean Architecture comme cadre pour empêcher les développeurs d’en sortir, en suivant un modèle à la lettre. Faire sans comprendre, sans réfléchir ne mène pas très loin. À quel point cela vaut le coup, de rendre des choses difficiles, d’ajouter de la complexité pour empêcher des développeurs de sortir des rails ? Il y a peut-être d’autres choix à explorer.

Dans tout ça, on oublie le pourquoi. On se concentre trop sur le comment. Pourquoi on l’utilise ? “C’est pour découper. C’est pour pouvoir tester.” me dit-on souvent, sans trop détailler. Oui, mais pourquoi ça devient “plus découpé”, “plus testable” ? Quels concepts y a-t-il derrière ? Pourquoi fait-on cela ?

Et si on se recentrait sur le métier ?

Le métier est la partie la plus importante du produit. Sans métier, le produit n’existerait pas, l’équipe ne le fabriquerait pas. C’est le cœur du programme et de l’entreprise. Certaines règles vont au-delà du programme. La répartition des places dans un train par exemple. Cette règle peut être présente dans plusieurs programmes différents et existe même en dehors de tout ça, dans le monde réel.

Ces règles ne dépendent pas d’un choix technique ou d’un framework, elles ne sont pas affectées par un changement technique. On change de base de données ? Pas de problème. On n’a pas encore choisi la base de données ? Pas de problème non plus. On change de framework ? Aucun souci.

Les règles devraient pouvoir changer aisément, le monde évolue constamment. On devrait les trouver et les comprendre facilement puisque c’est le cœur du programme. C’est pour toutes ces raisons qu’il est important d’apporter une grande attention sur cette brique. De la protéger de l’extérieur. De la rendre compréhensible, lisible. De la tester.

Le schéma de Clean Architecture représenté par les 4 cercles va d’ailleurs dans ce sens. On retrouve les règles métiers et les règles applicatives au centre. Et uniquement ça. Pas de framework, pas de base de données, pas d’interface graphique. Les frontières protègent les cercles à l’intérieur de l’extérieur. C’est aussi l’esprit de l’architecture hexagonale et du DDD (Domain-Driven Design).

Le métier est au centre parce qu’il est très important. Parce qu’on veut le protéger. Parce qu’on veut en prendre soin. Le reste, c’est du détail. Du détail d’implémentation.

Et si on se penchait sur les principes ?

La programmation orientée-objet a son rôle à jouer, bien plus que ce que l’on apprend souvent à l’école (vous savez, ce fameux héritage pour classifier des animaux). Certains concepts qui gravitent autour de la POO se cachent derrière la Clean Architecture et sa séparation des couches.

L’abstraction par exemple. Avec l’abstraction, on cache les détails de l’implémentation. On veut utiliser quelque chose sans savoir comment ça fonctionne derrière. On s’enlève cette complexité. Je veux enregistrer un favori sans savoir de quelle manière il sera stocké.

L’inversion de contrôle et l’injection de dépendances sont un autre exemple. Ces concepts sont présents pour renforcer les frontières, pour protéger les cercles. On veut que les cercles discutent entre eux, mais sans qu’un cercle intérieur n’ait connaissance d’un cercle extérieur. On découple. Un Use Case peut interagir avec une base de données sans que ce code ne soit à l’intérieur du cercle, de son module. Cette brique est indépendante. Ainsi, les changements autour de la base de données ne vont pas affecter le Use Case. Et c’est tout de même le Use Case qui est aux commandes, qui utilise la base de données.

On parle de modularité en programmation orientée objet. D’autres concepts sont également là. Je vous conseille de prendre le temps de les découvrir et de les comprendre. De voir comment tout cela s’articule, et d’aller au-delà de la Clean Architecture. S’ils ne vous intéressent pas, alors prenez encore plus de temps pour creuser le sujet. Mais n’en restez pas à l’application d’un pattern.

Et si on explorait plus loin ?

La Clean Architecture apporte de bonnes choses, mais ce n’est pas une silver bullet pour autant. La solution miracle n’existe pas. C’est une solution parmi d’autres. Il faut la comprendre, savoir ses forces et faiblesses, connaître ses principes, l’approfondir.

Il faut également explorer ce qu’il y a autour. L’architecture hexagonale est une approche similaire par exemple. Elle accorde beaucoup d’importance au métier, le place au centre et le protège avec un système de ports et d’adapters. Une approche simple qui se marie très bien avec le Domain-Driven Design (un tas de choses à voir là-dedans, je recommande pleinement de s’y plonger). Le Functionnal Core, Imperative Shell me semble être un autre moyen intéressant.

Et il faut garder en tête les différents principes de programmation. Ils sont toujours là, peu importe le choix de l’architecture. Ils vous accompagneront pendant longtemps.

Cherchez à comprendre et approfondissez, n’appliquez pas sans réfléchir. Soyez ouvert et explorateur, ne restez pas enfermé dans une vision unique. Et appréciez :)