Une application peut être belle à l’extérieur, mais si l’architecture interne est mauvaise, elle sera lente, difficile à maintenir et pleine de bugs. L'Architecture logicielle définit la façon dont les parties du code sont organisées et communiquent entre elles. C'est la fondation du bâtiment.
Si vous démarrez ou avez hérité d'un projet existant, comprenez les fondamentaux pour ne pas construire un château de cartes.
Qu'est-ce qu'une bonne architecture ?
Une bonne architecture doit être :
- Évolutif : ajout facile de nouvelles fonctionnalités sans casser les anciennes.
- Testable : Facile à écrire tests automatisés.
- Maintenable : tout nouveau développeur doit comprendre le code rapidement.
Normes communes (soupe à l'alphabet)
MVC (Modèle-Vue-Contrôleur)
Le classique.
- Modèle : Données.
- Vue : Écran.
- Contrôleur : Logique qui connecte les deux.
- Problème : Dans les applications mobiles, le Controller a tendance à devenir gigantesque (Massive View Controller), concentrant trop de responsabilités.
MVVM (Modèle-Vue-ViewModel)
La norme industrielle moderne (Android Jetpack, iOS Swift UI).
- ViewModel : prépare les données spécifiquement pour la vue à afficher. La vue « observe » le ViewModel. Si les données changent, l'écran se met à jour (Réactivité).
- Avantage : Il sépare très bien la logique de l'interface.
Architecture propre
Proposé par Robert C. Martin (Oncle Bob). Divise l'application en couches (oignon).
- Core (Domain) : règles métier pures (ils ne savent pas que c'est une application).
- Données : référentiels, API, base de données.
- Présentation : UI, ViewModels. La règle est la suivante : les couches à l’extérieur connaissent les couches à l’intérieur, mais les couches à l’intérieur NE connaissent PAS les couches à l’extérieur. Le Core ne sait pas s'il fonctionne sur un iPhone ou un micro-ondes.
Erreurs fondamentales
- Logique dans l'interface utilisateur : placez les règles métier ("si le solde < 0, coloriez-le en rouge") directement dans le fichier d'écran. Cela rend impossible le test sans exécuter l’émulateur.
- Couplage fort : Si vous modifiez la bibliothèque API (Retrofit) et devez réécrire les écrans, votre couplage est erroné. Utilisez l’injection de dépendances.
- God Objects : Classes qui font tout (appeler l'API, enregistrer dans la base de données, formater les données). Répartir en petites classes avec une seule responsabilité (SOLIDE).
Conclusion
Il n’existe pas « d’architecture parfaite », il existe une architecture adaptée à la taille du projet. Pour un MVP, un simple MVC fera l'affaire. Pour une Super App, Clean Architecture est obligatoire. L’important est de choisir une norme et de la suivre de manière cohérente.
A lire aussi
-Backend pour les applications : bonnes pratiques pour les petites équipes qui ne peuvent pas se tromper -Candidature pour les startups - Liste de contrôle quotidienne
- Application pour les startups : la liste de contrôle de ce qui compte vraiment avant de évoluer -Comment faire évoluer une application - Comparaison avec l'échelle
- Architecture d'application : Guide complet des systèmes évolutifs -Architecture des applications - Meilleures pratiques pour les entreprises