3.2 Styles et motifs architecturaux

Vue d’ensemble et motivation

Un style architectural est une forme large et réutilisable pour organiser un système : comment il est décomposé, comment les parties communiquent, et où tombent les frontières. En choisir un est parmi les décisions les plus lourdes de conséquences (et les plus mal comprises) qu’une grande organisation prend. Trop souvent, le choix suit la mode (« tout le monde fait des microservices ») plutôt que les vraies contraintes de l’équipe, du domaine, et de la réalité opérationnelle. Vous finissez avec l’un de deux désordres : un système distribué que l’organisation ne peut pas exploiter, ou un monolithe emmêlé que personne ne peut changer en sécurité. Ni l’un ni l’autre n’est la faute du style. Les deux viennent d’un mauvais appariement entre le style et la situation.

Pour les grandes équipes de développeurs, les styles comptent avant tout à cause de la loi de Conway : la structure d’un système tend à refléter la structure de communication de l’organisation qui le construit. Donc un style architectural est aussi une décision de conception organisationnelle. Diviser un système en services est réellement une décision de diviser des équipes, de la propriété, et de la responsabilité d’astreinte. Les entreprises avec des centaines d’ingénieurs peuvent se permettre (et ont souvent besoin) de services à grain fin avec un déploiement indépendant, parce que cette indépendance est comment de nombreuses équipes livrent sans se bloquer mutuellement. Forcez le même motif sur une seule petite équipe, et elle hérite de toute la taxe opérationnelle sans aucun des bénéfices organisationnels.

Les contextes gouvernementaux et d’entreprise ajoutent plus de contraintes : de longues durées de vie de système, un contrôle des changements strict, des cycles d’approvisionnement, une intégration avec des systèmes de référence bien ancrés, et l’auditabilité. Cela favorise des styles qui gardent les frontières explicites et les dépendances faciles à inspecter. Ce chapitre passe en revue les styles majeurs : du monolithe aux microservices, les architectures pilotées par les événements avec CQRS et le sourcing d’événements, les motifs de maillage de services et de passerelle, le sans serveur, et les disciplines internes de l’architecture hexagonale et propre. Plus important encore, il vous aide à discerner quand chacun convient.

Voir aussi : chapitre 2.2 (principes de conception logicielle, incluant la conception pilotée par le domaine), chapitre 3.1 (fondamentaux de l’architecture), et chapitre 3.3 (systèmes distribués).

Principes clés

Le style suit les forces, pas la mode. Choisissez selon la taille d’équipe, la complexité du domaine, la charge, et la maturité opérationnelle, jamais parce qu’une technologie est populaire.
Le couplage est le vrai ennemi, pas le nombre de déployables. Un monolithe bien modularisé bat une grande boule de boue distribuée.
La distribution est un coût que vous payez pour l’indépendance. Ne divisez que quand la valeur du déploiement indépendant, de la mise à l’échelle, ou de l’isolation de panne dépasse le coût des appels réseau, de la panne partielle, et de la cohérence des données à travers les services.
Les frontières devraient suivre le domaine métier. Alignez les services et les modules sur des contextes bornés (chacun un modèle de domaine autonome avec sa propre frontière explicite), pas sur des couches techniques.
Concevez bien l’intérieur, quel que soit l’extérieur. La stratification hexagonale/propre garde la logique métier indépendante des frameworks et de l’infrastructure dans chaque style.
La loi de Conway est inéluctable, donc utilisez-la. Concevez ensemble les frontières d’équipe et l’architecture.
Commencez plus simple que vous ne pensez en avoir besoin. Vous pouvez extraire des services d’un bon monolithe modulaire ; dé-distribuer un désordre de microservices prématuré est bien plus difficile.

Recommandations

Par défaut sur un monolithe modulaire ; diviser avec des preuves

Commencez la plupart des systèmes comme une seule unité déployable avec des frontières de module internes fortes : des interfaces claires, aucune intrusion dans les données d’un autre module, et des règles de dépendance imposées. Vous obtenez des transactions simples, une refactorisation facile, et une seule chose à déployer et observer. Divisez un module en son propre service seulement quand vous avez une raison concrète : une partie qui doit s’échelonner seule, une équipe qui a besoin de déployer selon sa propre cadence, un domaine de panne que vous devez isoler, ou une exigence technologique qui diffère du reste. Quand vous divisez réellement, divisez le long des lignes de contexte borné pour que chaque service possède ses données et expose un contrat stable.

Savoir quand les microservices méritent leur place

Les microservices vous donnent la déployabilité indépendante, la mise à l’échelle indépendante, l’isolation de panne, et la liberté de mélanger des technologies. En retour, ils exigent un CI/CD mature (intégration continue et livraison continue), une infrastructure automatisée, un traçage distribué, la découverte de service, et une culture d’astreinte. Demandez-vous honnêtement : votre organisation peut-elle exploiter des dizaines de services déployés indépendamment en production de façon fiable ? Si la plateforme et la maturité opérationnelle ne sont pas là, les microservices multiplient simplement vos modes de défaillance sans livrer leurs bénéfices. De nombreuses organisations réussissent mieux avec une poignée de services à gros grain alignés sur les domaines majeurs plutôt qu’un essaim de petits.

Utiliser l’architecture pilotée par les événements là où le découplage et l’asynchronie rapportent

L’architecture pilotée par les événements permet aux producteurs d’émettre des faits sans savoir qui les consomme. Cela vous achète un couplage lâche, un tampon pour les pics de charge, et un moyen facile d’ajouter de nouveaux consommateurs. Utilisez-la là où les flux de travail sont naturellement asynchrones et réactifs. CQRS (Command Query Responsibility Segregation) sépare le modèle d’écriture d’un ou plusieurs modèles de lecture, ce qui aide quand les charges ou formes de lecture et d’écriture diffèrent nettement. Le sourcing d’événements stocke l’état comme un journal d’événements en ajout seul plutôt que comme un état actuel, vous donnant une piste d’audit parfaite et un voyage dans le temps. C’est puissant pour la finance et l’administration publique, où « comment sommes-nous arrivés à cette valeur ? » est une question légale, mais cela ajoute une vraie complexité dans le versionnage d’événements, la reconstruction de projections, et le raisonnement sur la cohérence éventuelle. Recourez-y délibérément, pas par défaut.

Appliquer les motifs de passerelle, BFF, et maillage pour gérer de nombreux services

Une passerelle API donne aux clients externes un point d’entrée unique, gérant l’authentification, la limitation de débit, le routage, et la terminaison TLS (Transport Layer Security). Un Backend-for-Frontend (BFF) donne à chaque type de client (web, mobile, API partenaire) sa propre couche d’agrégation sur mesure, pour que vous évitiez une API générique et gonflée. Un maillage de services déplace les préoccupations transversales (TLS mutuel, nouvelles tentatives, délais d’expiration, déplacement de trafic, et télémétrie) dans une couche d’infrastructure sidecar, pour que les équipes d’application n’aient pas à les réimplémenter. N’ajoutez un maillage qu’une fois que le nombre de services rend la gestion de ces préoccupations par service ingérable. Pour quelques services, un maillage est plus de poids opérationnel qu’il n’en vaut la peine.

Peser honnêtement le sans serveur

Les plateformes de fonction en tant que service et de sans serveur géré retirent la gestion de serveur de votre assiette, s’échelonnent jusqu’à zéro, et facturent à l’usage, ce qui est excellent pour les charges de travail irrégulières, pilotées par les événements, ou à faible référence de base, et pour les petites équipes. Les compromis sont réels : la latence de démarrage à froid, les limites de temps d’exécution et de ressources, des tests locaux plus difficiles, un possible enfermement fournisseur, et un coût qui peut dépasser l’infrastructure provisionnée à un volume élevé soutenu. Utilisez le sans serveur là où son économie et sa simplicité opérationnelle gagnent clairement. Ne forcez pas des systèmes centraux stables et à haut débit dedans par enthousiasme.

Garder la logique métier propre à l’intérieur de chaque service

Quel que soit le style extérieur, gardez l’intérieur propre avec l’architecture hexagonale (ports et adaptateurs) ou propre : les règles métier au centre, dépendant seulement d’abstractions ; les frameworks, bases de données, et messagerie aux bords comme adaptateurs remplaçables. Cela garde votre précieuse logique de domaine testable sans infrastructure et portable à travers les changements technologiques : un avantage décisif pour les systèmes d’entreprise et gouvernementaux de longue durée qui survivront à plusieurs générations de frameworks.

Compromis : avantages et inconvénients

Style	Meilleur quand	Avantages	Inconvénients
Monolithe modulaire	La plupart des systèmes, spécialement tôt	Opérations simples, transactions et refactorisation faciles	Unité de déploiement unique ; s’échelonne comme un tout ; risque d’érosion
Microservices	De nombreuses équipes, forte échelle, plateforme mature	Déploiement/échelle indépendants, isolation de panne	Complexité distribuée, cohérence des données, coût opérationnel élevé
Piloté par les événements / CQRS / sourcing d’événements	Flux asynchrones, besoins d’audit, lecture/écriture divergentes	Couplage lâche, auditabilité, lectures évolutives	Cohérence éventuelle, versionnage d’événements, débogage plus difficile
Sans serveur	Travail irrégulier ou à faible référence, piloté par les événements	Aucune gestion de serveur, échelle jusqu’à zéro, paiement à l’usage	Démarrages à froid, limites, enfermement, coût à forte charge soutenue

Le thème récurrent : vous achetez de la flexibilité et de l’indépendance avec de la complexité opérationnelle et cognitive. Les styles distribués et pilotés par les événements abandonnent la simplicité d’une seule pile d’appels et d’une seule transaction en échange de la capacité de s’échelonner, se déployer, et échouer indépendamment. Cet échange rapporte à l’échelle et avec une plateforme mature. Sans elle, il est ruineux. Les disciplines internes (hexagonale/propre) valent presque toujours la peine, parce qu’elles coûtent peu et gardent vos options ouvertes pour changer de style plus tard.

Questions à discuter avec votre équipe

Avant de diviser le prochain service, diviserez-vous l’équipe qui le possède, et qui a l’autorité de le faire ? La loi de Conway signifie qu’une frontière de service est réellement une frontière d’équipe, donc une division que l’organigramme ne soutient pas produit un monolithe distribué : deux déployables, un train de livraison, une astreinte partagée. Dans une grande entreprise, l’autorité de refaçonner les équipes se trouve généralement au-dessus de l’ingénierie, avec les lignes hiérarchiques, la finance, et les ressources humaines, ce qui est pourquoi l’architecture et la conception organisationnelle doivent être décidées ensemble. Apportez des preuves à la discussion : le service proposé a-t-il une équipe qui peut le posséder de bout en bout, doter sa propre astreinte, et déployer selon sa propre cadence ? Si la réponse est non, financez l’équipe ou gardez la capacité comme un module dans le monolithe. Diviser le code sans diviser la propriété achète chaque coût de la distribution et aucune de l’indépendance.
Pouvez-vous déployer chacun de vos services indépendamment aujourd’hui, ou livrent-ils secrètement en lockstep ? Le monolithe distribué est le pire résultat de ce chapitre : vous payez pour les appels réseau, la panne partielle, et la cohérence des données à travers les services, pourtant vous ne pouvez toujours pas livrer l’un sans les autres. Les signes révélateurs sont une base de données partagée, une bibliothèque partagée qui force des mises à niveau coordonnées, et des tests d’intégration qui doivent exécuter tout le parc ensemble. Pour une grande équipe, cela plafonne discrètement le débit, parce que chaque équipe fait la queue derrière une livraison même si le diagramme montre l’indépendance. Prenez un changement récent et comptez combien de services ont dû se déployer ensemble pour le rendre sûr ; si ce nombre est supérieur à un pour un changement qui touchait une seule capacité, vos frontières sont fausses. La correction est généralement de donner à chaque service ses propres données et un contrat versionné stable, pas d’ajouter plus de services.
Lesquelles de vos divisions de service existantes ont cessé de rapporter, et les consolideriez-vous de nouveau ? L’habitude la plus avancée du chapitre est de traiter les décisions de style comme réversibles : extrayez quand un moteur apparaît, et refusionnez quand le moteur disparaît. La plupart des organisations ne font que diviser, donc les nanoservices et les services d’entité bavards s’accumulent jusqu’à ce que l’orchestration et la surcharge réseau éclipsent le travail que fait chaque service. Cherchez des services qui se déploient toujours ensemble, qui existent à cause d’une table de base de données plutôt que d’une capacité métier, ou dont les sauts réseau dominent maintenant la latence d’une requête. Dans les parcs d’entreprise et gouvernementaux, où les effectifs et les budgets sont scrutés, replier deux services minces en un service à gros grain est un mouvement légitime et économe, pas un aveu d’échec. Mettez la reconsolidation sur la table aussi ouvertement que l’extraction, et décidez les deux avec la même preuve.
La maturité de votre plateforme et de votre astreinte soutient-elle réellement le style que vous proposez, et pouvez-vous nommer les lacunes spécifiques avant de vous engager ? Les microservices, les maillages, et les épines dorsales pilotées par les événements ne livrent leurs bénéfices que par-dessus un CI/CD mature, un traçage distribué, la découverte de service, et une culture d’astreinte capable de raisonner sur la panne partielle. Une grande organisation tend à décider le style cible dans un forum d’architecture et à découvrir la plateforme manquante plus tard, une fois que des dizaines de services sont déjà en production et que chaque incident prend des heures à diagnostiquer. Pesez l’attrait du déploiement et de la mise à l’échelle indépendants contre la question sobre de qui l’exploite à 3 heures du matin : la même division qui libère les équipes pour livrer en parallèle multiplie aussi les modes de défaillance que chaque équipe doit comprendre. Apportez un inventaire honnête à la discussion : fréquence de déploiement actuelle, temps moyen de récupération, si vous avez du traçage à travers les frontières de service, et combien de services une seule équipe peut réalistement exploiter. Dans les contextes d’entreprise et gouvernementaux, ajoutez les délais d’approvisionnement et de recrutement pour les capacités de plateforme qui vous manquent, parce qu’un style qui suppose un maillage et une équipe de plateforme que vous n’avez pas financée est un plan pour exploiter un parc insoutenable.
Pour quelles parties du domaine une piste d’audit entièrement sourcée par événements est-elle une nécessité légale plutôt qu’une commodité, et qui a l’autorité de décider ? Le sourcing d’événements et CQRS vous achètent un historique parfait et reconstructible et des modèles de lecture qui s’échelonnent seuls, mais ils vous coûtent le versionnage d’événements, les reconstructions de projection, et le raisonnement sur la cohérence éventuelle pour la vie du système. Appliquée à un domaine qui n’a jamais eu besoin de la piste d’audit, cette complexité est une pure taxe ; retenue d’un domaine où « comment sommes-nous arrivés à cette valeur ? » est une question légale, son absence est un échec de conformité. Les considérations concurrentes sont l’auditabilité et l’évolutivité des requêtes d’un côté, et la difficulté de débogage et la charge cognitive du développeur de l’autre, donc la décision appartient aux gens qui comprennent à la fois l’obligation réglementaire et le fardeau opérationnel, pas à qui est le plus enthousiaste au sujet du motif. Apportez les exigences légales ou contractuelles spécifiques de rétention et de reconstruction, le volume d’événements attendu, et une estimation honnête du travail de versionnage et de projection. En finance, fiscalité, et administration publique, où reconstruire une décision des années plus tard peut être un devoir légal, nommez le propriétaire responsable qui valide qu’un contexte borné donné exige, ou non, un journal d’événements immuable.
Comment empêcherez-vous le monolithe modulaire de s’éroder pour que l’extraction ultérieure reste bon marché, et qu’est-ce qui imposera les frontières ? Tout l’argument pour commencer avec un monolithe modulaire repose sur la promesse que des frontières internes propres rendent l’extraction de service ultérieure abordable, pourtant ces frontières se décomposent silencieusement au moment où une échéance tente un module de s’immiscer dans les données d’un autre. Pour une grande équipe avec de nombreux contributeurs, les bonnes intentions et la relecture de code seules ne tiendront pas la ligne ; sans mécanisme d’imposition, le monolithe devient discrètement la grande boule de boue que le style était censé éviter. Pesez la friction des règles de dépendance imposées et des interfaces de module contre le coût de découvrir, des années plus tard, qu’aucune frontière n’est réelle et que chaque extraction signifie démêler de l’état partagé. Apportez des preuves : les frontières de module sont-elles imposées par l’outillage de construction, l’analyse statique, ou la structure de paquet, ou sont-elles simplement des conventions documentées que les six dernières fusions ont ignorées ? Dans les systèmes d’entreprise et gouvernementaux de longue durée qui doivent survivre à un contrôle des changements strict et plusieurs générations de framework, traitez l’imposition de frontière comme un contrôle auditable, pour que l’option de distribuer plus tard en soit une que vous avez réellement préservée plutôt qu’une que vous supposez encore détenir.

Regard sectoriel

Jeune pousse. Par défaut sur un monolithe modulaire unique et résistez à l’attrait des microservices, parce que votre ressource la plus rare est l’attention d’ingénierie et qu’un essaim de services est une taxe opérationnelle que vous ne pouvez pas vous permettre avant l’adéquation produit-marché. Gardez des frontières de module propres pour pouvoir extraire plus tard, et recourez au sans serveur là où l’échelle-jusqu’à-zéro et le paiement à l’usage conviennent à votre charge irrégulière et à faible référence. Divisez exactement une chose seulement quand un moteur concret apparaît, comme un expéditeur de notification en rafale, et jamais plus tôt.

Petite entreprise. Sans équipe de plateforme et avec un budget serré, favorisez un monolithe ou une poignée de services à gros grain sur une plateforme gérée, et achetez de l’infrastructure hébergée plutôt que de construire des maillages, du traçage, et de la découverte de service vous-même. Pesez le sans serveur et les bases de données gérées comme un moyen d’éviter d’exploiter des serveurs du tout, et méfiez-vous d’une conception distribuée dont vous n’avez personne pour porter le fardeau opérationnel. La bonne architecture est celle qu’une ou deux personnes peuvent réellement déployer, observer, et récupérer.

Grande entreprise. Le vrai problème est de nombreuses équipes et la loi de Conway : alignez des services à gros grain sur des contextes bornés et sur la propriété d’équipe, et investissez délibérément dans la plateforme (CI/CD, traçage, maillage, et découverte de service) qui rend la distribution sûre. Standardisez les motifs de passerelle, BFF, et d’architecture propre interne pour que les groupes cessent de les réinventer, et gouvernez l’extraction et la reconsolidation comme des décisions de portefeuille fondées sur des preuves plutôt que la préférence locale. Budgétez explicitement le coût opérationnel de chaque division, parce qu’à votre échelle l’échec du monolithe distribué est coûteux et lent à défaire.

Gouvernement. Les longues durées de vie de système, le contrôle des changements strict, les cycles d’approvisionnement, et l’auditabilité façonnent le choix : favorisez des styles avec des frontières explicites et inspectables et des contrats durables qui survivent aux fournisseurs et aux générations de frameworks. Le sourcing d’événements mérite sa complexité là où reconstruire une décision orientée citoyen est un devoir légal, donc utilisez-le délibérément pour les grands livres centraux et gardez l’architecture propre à l’intérieur de chaque service pour isoler les règles qui changent avec chaque budget. Traitez la portabilité et la sortie du sans serveur propriétaire ou des plateformes fournisseur comme des exigences d’approvisionnement, pas des réflexions après coup.

Exemples

Jeune pousse. Une start-up de quatre personnes construisant un produit de planification ressent la pression de commencer avec des microservices parce qu’un concurrent en a parlé sur son blog, mais résiste. Elle livre un monolithe modulaire unique avec des frontières internes claires (planification, facturation, notifications) comme modules séparés dans un déployable, pour qu’un ingénieur puisse faire fonctionner tout localement et qu’une livraison soit un seul push. Alors que le produit trouve sa traction, seul l’expéditeur de notification, qui se ramifie vers l’email et le SMS sous charge en rafale, est extrait dans son propre service. Elle n’hérite d’aucune de la taxe opérationnelle d’une douzaine de services pendant qu’elle cherche encore l’adéquation produit-marché.

Grande entreprise. Une grande entreprise de commerce électronique commence comme un monolithe modulaire. À mesure que le trafic grandit et que les équipes se multiplient, elle extrait les domaines à plus forte charge et évoluant le plus indépendamment (catalogue, panier, paiement, et recherche) en services séparés, chacun possédant ses données. Le paiement émet des événements que l’inventaire, l’exécution, et l’analytique consomment à travers une épine dorsale d’événements, si bien que de nouveaux consommateurs (détection de fraude, fidélité) peuvent se rattacher sans toucher au paiement. Une passerelle API gère l’authentification et la limitation de débit, et un BFF adapte les charges utiles pour le mobile. Les domaines restants à trafic plus faible restent dans le monolithe, ce qui évite une fragmentation inutile.

Gouvernement. Une administration fiscale construit une plateforme d’évaluation sur le sourcing d’événements pour le grand livre central, parce que chaque changement à la responsabilité d’un contribuable doit être reconstructible et légalement auditable pendant des années. Les commandes (déposer une déclaration, appliquer un paiement, émettre un ajustement) produisent des événements immuables, et les modèles de lecture projettent les soldes actuels pour les agents et les citoyens. CQRS permet au côté requête orienté public de s’échelonner seul pendant la saison de dépôt de pointe sans mettre le côté écriture en danger. À l’intérieur, chaque service suit l’architecture propre, si bien que les règles d’évaluation, qui changent avec chaque budget, restent isolées de la technologie de persistance et de messagerie.

Argumentaire économique : motivations, retour sur investissement et coût total de possession

L’argent en jeu dans un choix de style est énorme, parce que la décision est coûteuse à inverser. Adoptez les microservices trop tôt et vous gonflez le coût total de possession à travers la construction de plateforme, l’infrastructure dupliquée, le débogage distribué, et un fardeau opérationnel plus lourd : des coûts qui restent avec vous pour la vie du système. Refusez de diviser un monolithe véritablement surchargé et vous plafonnez le débit de livraison : les équipes font la queue derrière une livraison partagée, et chaque changement met tout le système en danger. La conversation sur le retour sur investissement porte réellement sur l’assortiment de la dépense opérationnelle au besoin organisationnel.

Faites valoir cela auprès de la direction en termes de débit et de risque, pas de technologie. La déployabilité indépendante signifie plus d’équipes livrant en parallèle et des délais plus courts : de la vélocité d’affaires mesurable. L’isolation de panne signifie moins de pannes totales et un rayon d’impact plus petit : de la disponibilité mesurable et une protection réputationnelle. Mais soyez tout aussi honnête sur l’investissement de plateforme que chaque style exige : un maillage, du traçage, et une maturité CI/CD sont des prérequis, pas des extras optionnels, et leur coût appartient au CTP. Pour de nombreuses organisations, le chemin le moins cher est un monolithe bien modularisé maintenant, avec des frontières internes propres qui rendent l’extraction ultérieure bon marché. Cela vous achète l’option de distribuer sans payer pour cela avant d’en avoir besoin.

Anti-patterns et pièges

Monolithe distribué. Des services qui doivent être déployés ensemble et partagent une base de données : tout le coût de la distribution, aucune de l’indépendance.
Nanoservices. Des services si finement granulaires que l’orchestration et la surcharge réseau éclipsent le travail qu’ils font.
Microservices sans plateforme. Diviser avant d’avoir un CI/CD, du traçage, et une maturité d’astreinte ; les modes de défaillance se multiplient.
Services d’entité. Diviser par table de base de données (« service Utilisateur », « service Commande ») au lieu de par capacité métier, forçant des appels inter-services bavards pour chaque opération.
Sourcing d’événements partout. L’appliquer à des domaines qui n’ont pas besoin de piste d’audit, payant la taxe de complexité pour aucun bénéfice.
Passerelle comme monolithe. Mettre la logique métier dans la passerelle API, recréant un point de passage central.
Cœur couplé au framework. Logique métier emmêlée avec le framework web ou ORM (mapping objet-relationnel), rendant à la fois le test et le changement technologique pénibles.

Modèle de maturité

Niveau 1 (Initier) : Le style est choisi par mode ou par accident. Vous avez un monolithe emmêlé ou un désordre distribué accidentel, les frontières suivent des couches techniques ou l’histoire plutôt que le domaine, et les divisions se produisent réactivement quand quelque chose casse.
Niveau 2 (Développer) : Certaines équipes tracent des frontières de module délibérées à l’intérieur du monolithe ou montent quelques services à gros grain, et certaines préoccupations transversales sont gérées de façon cohérente. La pratique est inégale : un groupe aligne les services sur des contextes bornés tandis qu’un autre divise encore par table de base de données, et l’extraction reste ad hoc.
Niveau 3 (Standardiser) : Une approche documentée est imposée à travers l’organisation : les services s’alignent sur des contextes bornés et possèdent leurs données, les motifs de passerelle et BFF sont utilisés là où approprié, la stratification propre ou hexagonale interne est la norme, et chaque division exige un moteur énoncé. Les frontières de module sont imposées par l’outillage, pas seulement la convention.
Niveau 4 (Gérer) : Les décisions de style sont mesurées et contrôlées par rapport à des références. Vous suivez la fréquence de déploiement et le délai par service, le temps moyen de récupération, combien de services doivent se déployer ensemble pour un changement typique, et la latence de saut réseau, et vous comparez le coût de chaque division à l’indépendance qu’elle était censée acheter. La preuve, pas la préférence, guide si une frontière survit, et la dérive vers un monolithe distribué est attrapée par des métriques plutôt que par une panne.
Niveau 5 (Orchestrer) : L’architecture est intégrée à la conception organisationnelle et adaptée continuellement. Une plateforme mature (CI/CD, traçage, et maillage là où justifié) rend à la fois la distribution et la reconsolidation bon marché, les équipes extraient couramment quand un moteur apparaît et replient les services quand il disparaît, et les choix de style sont rééquilibrés à mesure que la topologie d’équipe, la charge, et le tableau de risque changent à travers tout le parc.

Pistes de réflexion

Où dans votre système un monolithe est-il réellement une force, et où est-il un vrai goulot d’étranglement ?
Quel moteur concret justifierait l’extraction de votre prochain service, et pouvez-vous le nommer avant de le construire ?
Votre organisation a-t-elle la maturité opérationnelle que les microservices exigent ? Que manque-t-il ?
Pour quelles parties de votre domaine une piste d’audit entièrement sourcée par événements est-elle une nécessité légale ou d’affaires contre un plus agréable-à-avoir ?
Dans quelle mesure vos frontières de service actuelles reflètent-elles vos frontières d’équipe, et cet alignement aide-t-il ou nuit-il ?
Si vous deviez changer votre framework web ou votre base de données l’année prochaine, quelle part de votre logique métier devriez-vous réécrire ?

Points clés à retenir

Choisissez le style architectural à partir de forces réelles (taille d’équipe, domaine, charge, maturité opérationnelle), pas de la mode.
Un monolithe modulaire est la bonne valeur par défaut pour la plupart des systèmes ; extrayez des services seulement avec un moteur concret et le long de lignes de contexte borné.
Les microservices échangent de la complexité opérationnelle et cognitive contre le déploiement indépendant, la mise à l’échelle, et l’isolation de panne ; ils exigent une plateforme mature.
Piloté par les événements, CQRS, et sourcing d’événements offrent un découplage et une auditabilité au coût d’une cohérence éventuelle et d’une complexité de versionnage ; adoptez-les délibérément.
Les passerelles, BFF, et maillages dompent les parcs à de nombreux services mais ajoutent du poids ; introduisez-les quand l’échelle l’exige, pas avant.
Appliquez l’architecture hexagonale/propre à l’intérieur de chaque service pour garder la logique métier précieuse testable et durable à travers le changement technologique.

Références et lectures complémentaires

Sam Newman, Building Microservices et Monolith to Microservices
Chris Richardson, Microservices Patterns
Eric Evans, Domain-Driven Design
Vaughn Vernon, Implementing Domain-Driven Design
Robert C. Martin, Clean Architecture
Alistair Cockburn, « Hexagonal Architecture (Ports and Adapters) »
Gregor Hohpe et Bobby Woolf, Enterprise Integration Patterns
Martin Fowler, Patterns of Enterprise Application Architecture (et des articles sur CQRS et le sourcing d’événements)
Matthew Skelton et Manuel Pais, Team Topologies