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 a l'extension, ferme a la modification. L - Liskov Substitution : un objet de type enfant doit pouvoir remplacer un objet de type parent. I - Interface Segregation : preferez plusieurs interfaces specifiques a une seule interface generale. D - Dependency Inversion : dependez des abstractions, pas des implementations. Ces principes produisent du code modulaire, testable et maintenable.
2. Expliquez les differences entre architecture monolithique, microservices et serverless.
Monolithe : une seule application deployable. Simple a developper et deployer, mais difficile a scaler et a maintenir quand il grandit. Microservices : services independants par domaine metier. Scalabilite fine, deploiement independant, mais complexite operationnelle elevee. Serverless : fonctions executees a la demande, sans gestion de serveurs. Scalabilite automatique, cout a l'usage, mais cold starts et limites d'execution. Le choix depend de la taille de l'equipe, de la complexite 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 regle de dependance : les couches internes ne connaissent pas les couches externes. Couches (du centre vers l'exterieur) : Entities (regles metier), Use Cases (logique applicative), Interface Adapters (controllers, presenters, gateways), Frameworks & Drivers (base de donnees, web, UI). Le domaine metier est independant des frameworks, de la base de donnees et de l'UI, ce qui le rend testable et portable.
4. Comment choisir entre une base SQL et NoSQL ?
SQL (PostgreSQL, MySQL) : schemas fixes, transactions ACID, jointures complexes, maturite. Ideal pour les donnees relationnelles, les applications transactionnelles (e-commerce, banque). NoSQL : schemas flexibles, scalabilite horizontale, hautes performances pour des patterns d'acces specifiques. Types : documents (MongoDB), cle-valeur (Redis), colonnes (Cassandra), graphe (Neo4j). Le choix depend des patterns d'acces, de la coherence requise, et du volume de donnees. Beaucoup de systemes combinent les deux (polyglot persistence).
5. Expliquez le CAP theorem et ses implications.
Le theoreme CAP (Brewer) stipule qu'un systeme distribue ne peut garantir que 2 des 3 proprietes simultanement : Consistency (tous les noeuds voient les memes donnees), Availability (chaque requete recoit une reponse), Partition tolerance (le systeme fonctionne malgre des coupures reseau). Les partitions reseau sont inevitables, donc le vrai choix est CP (coherence, ex: PostgreSQL replica synchrone) ou AP (disponibilite, 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 metier. Concepts cles : Ubiquitous Language (langage commun entre developpeurs et experts metier), Bounded Context (frontiere explicite d'un modele de domaine), Aggregate (cluster d'entites traitees comme une unite), Entity (identite), Value Object (defini par ses attributs, immutable), Domain Event (fait significatif du domaine). Le DDD est particulierement utile pour les domaines metier complexes et guide naturellement le decoupage en microservices.
7. Comment concevoir un systeme pour la haute disponibilite ?
Strategies : redondance a tous les niveaux (serveurs, bases de donnees, regions), load balancing pour distribuer le trafic, replication de bases de donnees (primary-standby, multi-primary), failover automatique (detection de pannes et basculement), deployment multi-AZ/multi-region, circuit breakers pour isoler les pannes, graceful degradation (fonctionner en mode degrade plutot que tomber completement). Definissez des SLOs et mesurez la disponibilite reelle.
8. Expliquez les patterns de cache et les strategies d'invalidation.
Patterns : Cache-Aside (l'application gere le cache), Read-Through (le cache charge automatiquement les donnees manquantes), Write-Through (ecriture simultanee cache + DB), Write-Behind (ecriture dans le cache, synchronisation asynchrone vers la DB). Invalidation : TTL (expiration temporelle), event-based (invalidation sur modification), version-based (tag de version). La regle : "There are only two hard things in CS: cache invalidation and naming things." Commencez simple (TTL) et complexifiez si necessaire.
9. Comment documenter une architecture logicielle ?
Le modele C4 (Simon Brown) est recommande : Context (vue systeme et acteurs externes), Container (applications, bases de donnees, files), Component (modules internes d'un container), Code (classes et interfaces, rarement necessaire). Utilisez des Architecture Decision Records (ADR) pour documenter les decisions architecturales avec le contexte, les options evaluees et les consequences. Gardez la documentation legere, proche du code (dans le repo), et mise a jour a chaque decision significative.
10. Quels sont les tradeoffs les plus courants en architecture ?
Les decisions architecturales sont des tradeoffs : performance vs maintenabilite (optimiser trop tot complexifie le code), coherence vs disponibilite (CAP theorem), simplicite vs extensibilite (YAGNI vs flexibilite future), couplage vs performance (les appels directs sont plus rapides que la messagerie asynchrone), cout de developpement vs cout operationnel (serverless vs serveurs geres). Un bon architecte rend ces tradeoffs explicites, documentes, et alignes avec les besoins metier.