Questions d'entretien Architecture Logicielle
1. Quels sont les principes SOLID et pourquoi sont-ils importants ?
S - Single Responsibility : une classe n'a qu'une seule raison de changer. O - Open/Closed : ouvert à l'extension, ferme à la modification. L - Liskov Substitution : un objet de type enfant doit pouvoir remplacer un objet de type parent. I - Interface Segregation : préférez plusieurs interfaces spécifiques à une seule interface générale. D - Dependency Inversion : dependez des abstractions, pas des implémentations. Ces principes produisent du code modulaire, testable et maintenable.
2. Expliquez les différences entre architecture monolithique, microservices et serverless.
Monolithe : une seule application déployable. Simple à développer et déployer, mais difficile à scaler et à maintenir quand il grandit. Microservices : services indépendants par domaine métier. Scalabilité fine, déploiement indépendant, mais complexité opérationnelle elevee. Serverless : fonctions exécutées à la demande, sans gestion de serveurs. Scalabilité automatique, coût à l'usage, mais cold starts et limites d'exécution. Le choix dépend de la taille de l'équipe, de la complexité et des contraintes de performances.
3. Qu'est-ce que la Clean Architecture et comment l'appliquer ?
La Clean Architecture (Robert C. Martin) organise le code en couches concentriques avec une règle de dépendance : les couches internes ne connaissent pas les couches externes. Couches (du centre vers l'extérieur) : Entities (règles métier), Use Cases (logique applicative), Interface Adapters (controllers, presenters, gateways), Frameworks & Drivers (base de données, web, UI). Le domaine métier est indépendant des frameworks, de la base de données et de l'UI, ce qui le rend testable et portable.
4. Comment choisir entre une base SQL et NoSQL ?
SQL (PostgreSQL, MySQL) : schémas fixes, transactions ACID, jointures complexes, maturité. Idéal pour les données relationnelles, les applications transactionnelles (e-commerce, banque). NoSQL : schémas flexibles, scalabilité horizontale, hautes performances pour des patterns d'accès spécifiques. Types : documents (MongoDB), cle-valeur (Redis), colonnes (Cassandra), graphe (Neo4j). Le choix dépend des patterns d'accès, de la cohérence requise, et du volume de données. Beaucoup de systèmes combinent les deux (polyglot persistence).
5. Expliquez le CAP theorem et ses implications.
Le theoreme CAP (Brewer) stipule qu'un système distribue ne peut garantir que 2 des 3 propriétés simultanément : Consistency (tous les nœuds voient les mêmes données), Availability (chaque requête reçoit une réponse), Partition tolérance (le système fonctionne malgré des coupures réseau). Les partitions réseau sont inevitables, donc le vrai choix est CP (cohérence, ex: PostgreSQL replica synchrone) ou AP (disponibilité, ex: Cassandra, DynamoDB). En pratique, le choix est plus nuance (PACELC theorem).
6. Qu'est-ce que le Domain-Driven Design (DDD) ?
Le DDD est une approche de conception logicielle centree sur le domaine métier. Concepts clés : Ubiquitous Language (langage commun entre développeurs et experts métier), Bounded Context (frontiere explicite d'un modèle de domaine), Aggregate (cluster d'entités traitées comme une unité), Entity (identité), Value Object (défini par ses attributs, immutable), Domain Event (fait significatif du domaine). Le DDD est particulièrement utile pour les domaines métier complexes et guide naturellement le decoupage en microservices.
7. Comment concevoir un système pour la haute disponibilité ?
Stratégies : redondance à tous les niveaux (serveurs, bases de données, régions), load balancing pour distribuer le trafic, réplication de bases de données (primary-standby, multi-primary), failover automatique (détection de pannes et basculement), deployment multi-AZ/multi-region, circuit breakers pour isoler les pannes, graceful degradation (fonctionner en mode degrade plutôt que tomber complètement). Définissez des SLOs et mesurez la disponibilité réelle.
8. Expliquez les patterns de cache et les stratégies d'invalidation.
Patterns : Cache-Aside (l'application gere le cache), Read-Through (le cache charge automatiquement les données manquantes), Write-Through (écriture simultanee cache + DB), Write-Behind (écriture dans le cache, synchronisation asynchrone vers la DB). Invalidation : TTL (expiration temporelle), event-based (invalidation sur modification), version-based (tag de version). La règle : "There are only two hard things in CS: cache invalidation and naming things." Commencez simple (TTL) et complexifiez si nécessaire.
9. Comment documenter une architecture logicielle ?
Le modèle C4 (Simon Brown) est recommandé : Context (vue système et acteurs externes), Container (applications, bases de données, files), Component (modules internes d'un container), Code (classes et interfaces, rarement nécessaire). Utilisez des Architecture Décision Records (ADR) pour documenter les décisions architecturales avec le contexte, les options evaluees et les conséquences. Gardez la documentation légère, proche du code (dans le repo), et mise à jour à chaque décision significative.
10. Quels sont les tradeoffs les plus courants en architecture ?
Les décisions architecturales sont des tradeoffs : performance vs maintenabilité (optimiser trop tot complexifie le code), cohérence vs disponibilité (CAP theorem), simplicité vs extensibilité (YAGNI vs flexibilité future), couplage vs performance (les appels directs sont plus rapides que la messagerie asynchrone), coût de développement vs coût opérationnel (serverless vs serveurs gérés). Un bon architecte rend ces tradeoffs explicites, documentés, et alignes avec les besoins métier.