Monolithe modulaire ou microservices : choisir sans suivre la mode

Commencer par les frontières métier

Avant de choisir le nombre de services, il faut identifier les responsabilités : identité, catalogue, contrat, paiement, notification ou reporting. Chaque module possède son vocabulaire et ses règles. Une frontière est saine lorsque son comportement peut évoluer sans obliger les autres parties à connaître ses détails.

Microsoft recommande de concevoir les microservices autour des capacités métier et de rechercher couplage faible et forte cohésion. Ces principes valent aussi dans un monolithe modulaire. La différence est que l’appel entre modules reste dans le processus et que l’ensemble est déployé comme une unité.

Le monolithe modulaire est un choix d’architecture

Ce n’est pas un dossier où toutes les couches s’appellent librement. Chaque domaine expose une interface, protège ses invariants et limite l’accès direct à ses données. Les tests vérifient les dépendances. Cette organisation réduit le coût des transactions distribuées et simplifie le démarrage pour une petite équipe.

Il convient lorsque les domaines changent encore, que le volume reste modéré et qu’une seule équipe opère le produit. Un déploiement unique facilite migrations et diagnostic. En contrepartie, il faut investir dans les frontières internes pour éviter un bloc fortement couplé.

Les microservices achètent de l’indépendance

Un service indépendant peut être déployé, dimensionné et développé avec une technologie adaptée. Cette autonomie devient utile lorsque plusieurs équipes ont des rythmes différents, qu’un domaine porte une charge spécifique ou qu’une panne doit être isolée.

Mais chaque séparation transforme un appel de fonction en communication réseau. Il faut gérer délais, reprises, authentification, versions de contrat et observabilité. Une opération transactionnelle peut nécessiter une saga et des compensations. L’indépendance possède donc un prix mesurable.

• Séparer pour une raison métier ou opérationnelle explicite.
• Éviter une base partagée qui recrée le couplage.
• Prévoir logs corrélés, métriques, traces et reprise.

Utiliser une grille de décision

On peut noter chaque domaine selon six axes : déploiement indépendant, charge distincte, criticité, maturité de la frontière, équipe propriétaire et besoins technologiques. Si les scores restent faibles, un module interne suffit souvent. Lorsque plusieurs axes deviennent élevés, l’extraction peut être justifiée.

AWS présente la décomposition par capacité, sous-domaine ou transaction, ainsi que le Strangler Fig. Cette approche progressive évite une réécriture générale. Le monolithe continue de fonctionner pendant qu’un domaine bien compris devient un service.

Concevoir pour pouvoir changer d’avis

La meilleure architecture initiale rend les dépendances visibles. Des modules cohérents, des contrats internes et des événements métier permettent d’extraire plus tard une partie sans réinventer son modèle.

Le choix est réévalué lorsque l’équipe grandit, que les déploiements se bloquent ou que les charges divergent. L’architecture répond à des contraintes observées ; la suivre comme une identité empêche de reconnaître quand elle coûte plus qu’elle ne rapporte.

Organiser les données avant de séparer les processus

Une frontière de service est fragile si plusieurs équipes écrivent directement dans les mêmes tables. Dans un monolithe modulaire, chaque module peut déjà posséder ses tables, ses règles de migration et son interface d’accès. Cette discipline prépare une extraction future sans imposer immédiatement des appels réseau.

Lorsqu’un processus est séparé, les transactions atomiques deviennent des échanges. Il faut choisir entre cohérence immédiate et convergence, gérer les doublons et conserver un historique des événements. Une boîte d’envoi transactionnelle peut éviter qu’une modification métier soit validée sans que l’événement correspondant soit publié.

Décider avec une expérience limitée

Avant une migration générale, une équipe peut extraire une capacité peu couplée et mesurer ce qui change : durée de déploiement, incidents, latence, charge d’astreinte et autonomie réelle. Si les coûts dépassent les bénéfices, le retour doit rester possible. Cette expérience produit des données propres à l’organisation, plus fiables qu’une règle universelle.

Le résultat attendu n’est pas un nombre maximal de services. C’est une architecture dont les frontières restent compréhensibles, dont les pannes sont maîtrisables et dont l’équipe peut faire évoluer chaque capacité au rythme nécessaire.

• Nommer un responsable par domaine.
• Interdire les dépendances circulaires.
• Mesurer la fréquence réelle de déploiement.
• Inclure observabilité et exploitation dans le coût de décision.