En tant que développeur Android, vous avez sûrement fait face à des projets dont le code est contenu dans un seul module.
Si cette approche fonctionne pour un PoC (Proof of Concept) rapide, elle révèle vite ses limites : difficultés à ajouter des fonctionnalités, risques d’effets de bord et architecture logicielle fragile. Conséquence : prise de raccourcis dans le développement et une simple modification affectait énormément de composants (classes, interfaces etc…)
Heureusement, une solution puissante existe pour garantir la scalabilité de vos applications : l’architecture multi-module. 👏
Dans cet article, vous allez découvrir comment une architecture en multi-module va augmenter drastiquement la maintenabilité, la testabilité, l’évolution et la réutilisabilité de votre code 💪
Architecture en multi-module Android : De quoi s’agit-il ?
Une architecture en multi-module c’est comme une maison. Cette dernière est constituée de pleins d’éléments indépendants ayant un rôle défini (des mûrs, un toit, des fenêtres, des fondations, de la plomberie …) et chaque composants est connecté avec les autres ce qui permet à la maison de tenir et d’être fonctionnelle.
Dans le cadre d’un projet Android, une architecture en multi-module permet de structurer le code en plusieurs modules, chacun responsable d’une fonctionnalité spécifique.
Techniquement cela se traduit par créer de multiples module Gradle configuré en tant que bibliothèques (Kotlin ou Android)
Les avantages de modulariser un projet Android sont nombreux et permettent :
- Meilleure maintenabilité : En divisant le code de votre application en plusieurs modules, il est plus facile de le maintenir et de le mettre à jour. Vous pouvez travailler sur un module spécifique sans affecter les autres modules.
- Meilleure testabilité : L’architecture multi-module facilite la création de tests unitaires. Vous pouvez tester chaque module individuellement, ce qui vous permet de détecter et de corriger les problèmes plus rapidement.
- Meilleure réutilisabilité du code : Les modules peuvent être réutilisés dans d’autres projets. Cela permet de réduire le temps de développement et d’améliorer la qualité du code.
- Meilleure évolutivité : L’architecture multi-module permet d’ajouter facilement de nouvelles fonctionnalités à votre application. Vous pouvez créer un nouveau module pour chaque nouvelle fonctionnalité.
- Meilleure collaboration : L’architecture multi-module facilite la collaboration entre les développeurs. Chaque développeur peut travailler sur un module spécifique, ce qui permet de développer des applications plus rapidement et plus efficacement en évitant les breaking changes.
Deux exemples d’implémentation d’architectures en multi-module Android
En regardant sur internet, vous pouvez voir qu’il y a beaucoup de façons différentes d’implémenter une architecture en multi-module.
Je ne vais pas vous dire que telle ou telle implémentation est meilleure qu’une autre, tout dépend de vos besoins, de vos compétences et de la taille de votre application. Je vais plutôt vous présenter dans ce paragraphe les deux découpages que j’ai régulièrement vu et vous me direz en commentaires ce que vous en pensez 🙂
Imaginons une application Android permettant d’envoyer de la crypto monnaie. Cela signifie qu’il faut signer la transaction avec son portefeuille puis l’envoyer sur la blockchain de la crypto monnaie associée
Pour réaliser ce projet, deux solutions d’architecture sont possibles et c’est ce que nous allons voir dans ce paragraphe
Approche n°1 : La modularisation par couche (data, domain, présentation)
Le principe d’une architecture en multi-module par couche est de découper votre code en fonction de leur responsabilité respective.
Regardez le schéma ci-dessous pour mieux comprendre :
Chaque ligne représente un module Gradle. Le module app/ est l’application Android et les trois autres sont les différentes couches dont la responsabilité est :
- presentation/ : contient toutes les interfaces graphiques de l’application (Composables) et la logique permettant de les affichés (ViewModels)
- domain/ : contient toutes les règles métiers de l’application. Ici SignTransaction et SendTransaction
- data/ : contient toute la logique pour accéder aux données. Ici la communication avec le portefeuille crypto et la communication avec la blockchain.
Les termes domain et data sont des termes issus de la Clean Architecture d’Oncle Bob. Je ne vais pas les détailler ici car ce n’est pas le sujet mais n’hésitez pas à me le dire si cela vous intéresse 😉
Les avantages d’un projet en multi modules avec ce type de couches sont :
- Facile à mettre en place et à configurer
- Adapté si votre application est petite
Toutefois les inconvénients d’une telle architecture sont :
- Il est plus difficile de retrouver toutes les fonctionnalités implémentés dans l’application
- On peut facilement avoir des conflits lors d’un merge
- Les modules ne peuvent pas être facilement réutiliser dans d’autres projets
Les modules peuvent grandir très rapidement et faire beaucoup de choses au fur et à mesure que les fonctionnalités augmentent. C’est un exemple typique de violation du principe de la Responsabilité Unique (j’écrirai un article sur ce sujet si ca vous intéresse)
Approche n°2 : La modularisation par fonctionnalité (feature modules)
Ici le principe d’une architecture en multi-module par fonctionnalités est, comme son nom l’indique, de découper votre projet en fonction des différentes fonctionnalités
Le schéma précédent devient donc le suivant :
Les avantages d’un projet en multi modules par fonctionnalités sont :
- Adapté si votre application est volumineuse et contient beaucoup de fonctionnalités
- Peu de risques de conflits lors d’un merge
- Peuvent facilement être réutilisés dans différents projets
- On voit très rapidement les différentes fonctionnalités que contiennent votre application
- Respect de la Responsabilité Unique car chaque module implémente une seule et unique fonctionnalité
Toutefois les inconvénients d’une telle architecture sont :
- Plus long à mettre en place car chaque nouvelle fonctionnalité doit respecter un template prédéfini
- Bien gérer la visibilité des différents composants (classes, interfaces etc..) pour ne pas faire fuiter à l’extérieur des choses qui sont internes
- Demande des connaissances d’architecture avancées (exemple : Inversion de Dépendances…)
🎯 Conclusion
Vous avez maintenant compris qu’une architecture en multi-module permet de passer votre application à un niveau supérieur. Elle facilite la maintenance, l’évolutivité et vous permet de scaler rapidement.
Toutefois une bonne modularisation demande d’autres connaissances que seulement écrire du code. Il faut maîtriser les principes S.O.L.I.D et certains types d’architectures (telle que la Clean Architecture d’Oncle BOB…). Mais ces points méritent de nouveaux articles 🙂
En modularisant votre projet, vous allez rapidement remarquer que certains scripts build.gradle vont être dupliqués mais heureusement j’ai écrit un article à ce sujet que vous pouvez retrouver ici
Si vous avez des questions, des remarques etc… n’hésitez pas à les poser dans les commentaires. Et si vous souhaitez que j’écrive un article sur un sujet particulier, dites-le moi ! 😊
Liens utiles :
