Introduction
La relation entre les Bounded Contexts, pierre angulaire du Domain-Driven Design (DDD), et les microservices est au cœur des débats parmi les architectes de systèmes logiciels. La conception largement répandue qui consiste à aligner directement les Bounded Contexts sur des microservices nécessite une analyse nuancée.
Dans son analyse critique, Vladik Khononov met en lumière que si l'identification des frontières est essentielle, l'équivalence systématique entre contextes et micro-services peut s'avérer simpliste.
D'autre part, la présentation Model Mitosis par Julien Topçu et Josian Chevalier offre une métaphore biologique pour explorer le découpage des services de domaine, présentant des stratégies pour faire évoluer les applications sans qu'elles ne deviennent des monolith legacy et pour éviter de tomber dans les pièges des microservices.
Cet article introduit une méthode complémentaire : la topologie des services de domaine.
Cette approche tente d'offrir un ensemble d'heuristiques essentielles à la conceptualisation d'une architecture DDD efficiente. Cet ensemble de stratégies et de pratiques est conçu pour guider les développeurs à travers le processus complexe de découpage des services, veillant à ce que chaque composant soit aligné avec les objectifs métier et les contours définis par les Bounded Contexts. L'approche suggérée cherche à optimiser la cohérence, la maintenance et l'évolutivité de l'architecture en se concentrant sur des services clairement délimités, cohérents et maniables.
NOTE
Avant de plonger dans les détails de cette approche, il est essentiel de préciser que le terme 'service' tel qu'utilisé ici fait référence à des artefacts de déploiement, plutôt qu'à des classes ou composants logiciels. Cela signifie que lorsque nous discutons de services dans le contexte de cet article, nous parlons d'unités déployables indépendantes qui peuvent être mises en service, gérées, et évoluées séparément. Chaque 'service' est donc un artefact opérationnel qui expose ses capacités via une API et qui peut interagir avec d'autres services pour former une architecture logicielle complète.
Rappel sur le DDD et les Bounded Contexts
Le Domain-Driven Design est une approche de conception logicielle qui met l'accent sur la complexité des systèmes en s'attachant étroitement aux règles et à la logique du domaine métier. Cette philosophie de développement est centrée sur la collaboration entre les experts du domaine et les développeurs pour créer des modèles linguistiques et conceptuels partagés qui favorisent une compréhension et une implémentation cohérentes des exigences métier au sein du logiciel.
Au cœur du DDD se trouve le concept de `Bounded Context`, qui définit les frontières contextuelles au sein desquelles un modèle de domaine particulier est défini et applicable. Chaque bounded context encapsule une logique métier spécifique, et son isolation aide à maintenir l'intégrité du modèle en évitant les ambiguïtés et en réduisant les conflits de terminologie entre les différentes parties du système. C'est cette segmentation stratégique qui permet à des systèmes complexes d'être décomposés en composants plus gérables et mieux définis, facilitant ainsi leur développement, leur évolution et leur maintenance.
Dans sa présentation intitulée Hexagonal at Scale, Cyril Martraire aborde l'importance des Bounded Contexts pour le découpage efficace des services expliquant comment définir des limites claires peut prévenir des problèmes lors du déploiement et de l'exécution. Cette présentation fournit des conseils pratiques avec clarté et pertinence. La maîtrise des concepts présentés dans cette présentation constitue un prérequis indispensable à l'application efficace de la typologie des services de domaine proposée ici.
Bounded Context et Équipe : Un Alignement Stratégique
Le DDD recommande un alignement étroit entre une équipe et un bounded context. Idéalement, une équipe est entièrement dédiée à un seul bounded context, ce qui lui permet de se concentrer sur la compréhension et la modélisation de ce segment spécifique. Cet alignement favorise une expertise approfondie et une responsabilité claire, essentielles pour le développement d'un modèle de domaine cohérent et robuste.
Scénarios d'alignement
1. Un bounded context, plusieurs équipes
Lorsqu'un bounded context est trop vaste ou semble nécessiter plusieurs équipes, cela peut souvent indiquer un problème de découpage. Idéalement, un bounded context devrait être suffisamment délimité pour être gérable par une seule équipe. Si ce n'est pas le cas, il peut être nécessaire de revoir la délimitation des bounded contexts pour s'assurer qu'ils représentent correctement des sous-domaines distincts.
2. Un bounded context, une équipe
Chaque bounded context correspond à un domaine ou à un sous-domaine spécifique et est géré de manière autonome par une équipe dédiée. Il s'agit de "la norme" en DDD.
3. Une équipe, plusieurs bounded contexts
Dans les petites organisations ou les projets moins complexes, une seule équipe peut être en charge de plusieurs bounded contexts. Cette approche nécessite une grande discipline pour maintenir la séparation claire et la cohérence des modèles de domaine.
NOTE
La décision de structurer les services celon la topologie des services de domaine dépend fortement de la taille et de la composition des équipes disponibles. Il est important de noter que les critères de choix que nous explorerons dans les sections suivantes doivent être considérés en tenant compte de cette réalité organisationnelle, car les ressources humaines et les compétences disponibles peuvent influencer de manière significative la manière dont les services sont conçus et gérés.
Topologie des Services
La topologie des services de domaine propose une approche réfléchie pour le découpage des services au sein d'une architecture guidée par le Domain-Driven Design (DDD).
Fondée sur une analyse approfondie des bounded contexts déjà établis, cette topologie permet de déterminer le découpage optimal des services pour soutenir les dynamiques métier.
En établissant des critères clairs qui offrent des heuristiques de découpage des services à partir de la définition des bounded contexts, la topologie des services de domaine ouvre la voie à une conception de services judicieusement alignés sur les exigences non-fonctionnelles.
Types de services
1. Monolith Modular Service
Ce type de service englobe plusieurs bounded contexts, chacun sous forme de module distinct au sein d'un déploiement monolithique. Cela permet une séparation conceptuelle tout en conservant un déploiement unifié.
Chaque module (bounded context) expose ses fonctionnalités sous forme d'API. Ces API sont conçues non seulement pour les interactions internes entre les modules du monolithe, mais aussi pour être accessibles par des services extérieurs. Elles agissent comme des endpoints bien définis qui reflètent les opérations et les concepts du domaine associé à chaque module. Chaque API représente fidèlement les opérations et les concepts de leur domaine respectif sans divulguer les détails d'implémentation ou l'architecture interne.
2. Bounded Context Service
Ce type de service est aligné avec un unique bounded context. Cela signifie que le service est conçu pour incarner entièrement le modèle d'ubiquité et les frontières définies par ce bounded context spécifique, offrant une congruence parfaite entre les frontières conceptuelles et physiques.
Les Bounded Context Services sont conçus pour fonctionner de manière indépendante. Ils exposent leurs fonctionnalités via une API qui représente fidèlement les opérations et les concepts du domaine sans divulguer les détails d'implémentation ou l'architecture interne.
3. Bounded Context Subservice
Un bounded context peut être scindé en plusieurs (sub)services. Cela permet de découper un bounded context complexe en unités de déploiement plus petites et plus gérables, chacune responsable d'une portion du modèle de domaine global ou plus souvent sous forme d'anti-corruption layer (ACL).
Chacun de ces sous-services peut techniquement exposer sa propre API pour être consommé par des services externes. Cependant, cela pourrait conduire à une complexité accrue et à une connaissance éparpillée de la structure interne du bounded context par les consommateurs externes. Pour maintenir une cohésion forte et une interface de domaine cohérente, une façade doit être responsable de l'orchestration des appels aux différents sous-services et doit représenter fidèlement les opérations et les concepts du domaine sans divulguer les détails de l'architecture interne.
NOTE
L'utilisation d'un service distinct en tant que façade n'est pas impérative. Un des micro-services au sein du bounded context peut agir comme le point d'entrée principal.
Heuristics
Les avantages et inconvénients identifiés dans cette section servent d'heuristiques pour orienter le choix de la toplogie des services de domaine. Ils constituent un guide pour examiner de manière structurée l'impact potentiel de chaque type de service sur des aspects critiques tels que la performance, l'évolutivité, l'intégrité du domaine, et l'efficacité opérationnelle. En considérant ces facteurs, les développeurs peuvent déterminer la structure de service qui aligne au mieux l'architecture technique avec les exigences et les dynamiques du métier.
Pour distinguer les quatre catégories de services, j'ai sélectionné dix-sept critères de différenciation. Ces critères offrent une perspective détaillée sur les avantages et inconvénients de chaque service. Bien que certains de ces critères puissent se chevaucher, ils fournissent ensemble une compréhension solide des forces et faiblesses de chaque option, facilitant ainsi le choix de la solution la plus adaptée à vos besoins spécifiques
1. Clarté de l'Architecture
Ce critère correspond à la facilité avec laquelle la structure du système peut être comprise, notamment en termes de services et de communication entre eux.
Monolith Modular Service
- Pros : L'architecture est souvent simple à comprendre car tous les modules sont centralisés. Les développeurs peuvent voir l'ensemble du système en un seul endroit, ce qui peut faciliter la compréhension et la navigation.
- Cons : Peut devenir complexe et enchevêtré si les modules ne sont pas bien délimités, menant à ce qu'on appelle le "Big Ball of Mud".
Bounded Context Service
- Pros : Fournit une clarté forte en isolant la logique métier dans des limites bien définies, ce qui rend chaque service plus compréhensible individuellement.
- Cons : La compréhension globale du système peut être plus complexe, car il faut comprendre les interactions entre de multiples services.
Bounded Context Subservice
- Pros : Chaque sous-service a des responsabilités spécifiques, ce qui rend la structure de l'architecture plus compréhensible. Pour les ACLs, ce découpage offre une frontière nette entre le système et les systèmes tiers, clarifiant les points d'interaction et d'intégration.
- Cons : Peut introduire une complexité si le contexte n'est pas intuitivement divisé: la multiplication des sous-services peut rendre difficile la perception de l'architecture comme un tout cohérent.
2. Autonomie de déploiement
Ce critère représente la capacité à déployer ou mettre à jour un service de manière indépendante sans impacter les autres composants.
Monolith Modular Service
- Pros : La gestion des dépendances est simplifiée car tout est déployé ensemble, ce qui réduit les risques de problèmes de compatibilité entre modules.
- Cons : Les déploiements sont plus lourds et moins fréquents, car ils impliquent généralement le redéploiement de tout le système, même pour des changements mineurs dans un seul module.
Bounded Context Service
- Pros : Chaque service, qui ne dépend que d'une équipe, peut être déployé indépendamment, permettant des cycles de mise en production rapides et spécifiques à chaque contexte.
- Cons : Nécessite une gestion plus fine des versions et de la coordination entre les équipes, car les changements peuvent affecter les interfaces partagées.
Bounded Context Subservice
- Pros : Permet des déploiements encore plus ciblés et fréquents, idéaux pour les mises à jour rapides et les expérimentations. Dans le cas de service ACL, une mise à jour de la thirdparty n'impacte que le déploiement de ce service spécifique.
- Cons : Peut augmenter la complexité de la gestion des versions et la coordination, car les modifications affectent une partie d'un contexte plus large.
3. Complexité de gestion
Ce critère mesure de la difficulté à surveiller, gérer et orchestrer les services dans un écosystème.
Monolith Modular Service
- Pros : Centralisation de la gestion, ce qui simplifie le suivi des modules dans un unique système de surveillance et de journalisation.
- Cons : Les changements liés aux outils de gestion, comme la surveillance ou la journalisation, sont susceptibles d'impacter tous les modules à la fois. Ce couplage crée des risques lors des mises à jour, pouvant provoquer un effet en cascade sur l'ensemble du système et nécessitant une gestion prudente pour éviter des perturbations généralisées.
Bounded Context Service
- Pros : Chaque BCS ayant un domaine délimité, la gestion est focalisée et simplifiée par contexte, ce qui rend la gouvernance plus cohérente.
- Cons : Il faut gérer la cohérence et la synchronisation entre les différents BCS, ce qui peut devenir complexe dans les systèmes étendus.
Bounded Context Subservice
- Pros : Peut réduire la complexité de gestion en isolant des fonctionnalités spécifiques pour une gestion et une évolution indépendantes.
- Cons : Nécessite une coordination fine pour assurer que les services partiels restent alignés avec la vision globale du bounded context.
4. Scalabilité
Ce critère représente l'aptitude du service à gérer l'augmentation de la charge de travail par l'ajout de ressources, de manière horizontale (plus d'instances) ou verticale (instances plus puissantes).
Monolith Modular Service
- Pros : La scalabilité peut être gérée de façon centralisée, permettant des économies d'échelle et une répartition des charges efficace en interne.
- Cons : La capacité à scaler peut être limitée par des goulots d'étranglement internes, car scaler tout le monolithe en réponse à la demande d'un seul module peut être inefficace et coûteux.
Bounded Context Service
- Pros : Excellente capacité à scaler verticalement ou horizontalement chaque service individuellement en fonction de ses besoins propres, ce qui optimise l'utilisation des ressources.
- Cons : Peut conduire à une complexité opérationnelle accrue car il faut gérer la scalabilité de multiples services indépendants.
Bounded Context Subservice
- Pros : Permet de scaler des parties spécifiques du système qui ont des exigences de performance distinctes, sans affecter l'ensemble du bounded context.
- Cons : Peut introduire une complexité dans la surveillance et la gestion de la performance, car les composants doivent être équilibrés soigneusement pour maintenir la performance globale du contexte.
5. Performances
Ce critère s'attache à la vitesse et à l'efficacité avec lesquelles un service exécute les demandes et les processus.
Monolith Modular Service
- Pros : Les interactions internes au sein d'un monolithe sont souvent plus rapides que les appels réseau, ce qui peut conduire à de meilleures performances pour les opérations fortement interdépendantes.
- Cons : Des performances inégales peuvent survenir si un module particulier n'est pas optimisé, ce qui peut affecter l'ensemble du monolithe.
Bounded Context Service
- Pros : Chaque service peut être optimisé pour ses propres exigences de performance, permettant une réactivité et une efficacité maximales sur des opérations spécifiques.
- Cons : Les appels réseau entre services peuvent introduire une latence supplémentaire, et la complexité de la synchronisation entre services peut affecter les performances globales.
Bounded Context Subservice
- Pros : Permet une optimisation ciblée et des performances élevées pour des fonctionnalités spécifiques sans la surcharge de l'ensemble du contexte.
- Cons : Les dépendances avec d'autres parties du même bounded context peuvent créer des goulets d'étranglement et des incohérences de performances.
6. Couplage et Cohésion
Ce critère indique le degré de dépendance entre les services (couplage) et la mesure dans laquelle les responsabilités au sein d'un service sont étroitement liées (cohésion).
Monolith Modular Service
- Pros : Une haute cohésion peut être maintenue à l'intérieur des modules, et le couplage peut être bien géré si les modules sont conçus avec des interfaces claires et des mécanismes d'interaction bien définis.
- Cons : Le risque de couplage fort entre modules est accru en raison de la facilité d'accès direct aux fonctionnalités des autres modules, ce qui peut nuire à la modularité.
Bounded Context Service
- Pros : La cohésion est forte car chaque service est aligné sur un seul bounded context. Le couplage est généralement faible entre les services, car ils communiquent via des interfaces ou des contrats définis.
- Cons : Si mal conçu, un BCS peut toujours avoir des dépendances cachées qui augmentent le couplage, par exemple, à travers des données partagées ou une logique métier implicite.
Bounded Context Subservice
- Pros : Les services partiels peuvent être très cohésifs s'ils sont responsables d'une fonctionnalité précise ou d'un sous-ensemble de fonctionnalités dans un bounded context.
- Cons : Ils peuvent introduire un couplage inattendu si la séparation entre les services partiels n'est pas claire ou si les services doivent souvent communiquer entre eux pour accomplir des tâches.
7. Redondance de code
Ce critère concerne la répétition du même code à travers différents services, pouvant affecter la maintenance et l'évolution.
Monolith Modular Service
- Pros : Moins susceptible de redondance de code, car les modules partagent le même espace de code et peuvent réutiliser des fonctionnalités communes facilement.
- Cons : Si les modules ne sont pas correctement isolés, cela peut conduire à une redondance involontaire lorsque les développeurs dupliquent la logique pour éviter les dépendances complexes.
Bounded Context Service
- Pros : La redondance peut être minimisée au sein d'un BCS car toute la logique est centrée autour d'un seul contexte métier.
- Cons : Entre différents BCS, des duplications peuvent survenir, spécialement si des fonctionnalités ou des concepts métier se chevauchent, étant donné que le partage de code entre services est généralement évité pour maintenir l'autonomie.
Bounded Context Subservice
- Pros : La redondance est généralement faible à l'intérieur d'un bounded context car le service est fortement spécialisé.
- Cons : Si la fonctionnalité du service doit être reproduite dans d'autres parties du système, cela peut conduire à une duplication de code.
8. Maintenance
Ce critère représente la facilité avec laquelle le système peut être corrigé, amélioré ou mis à jour.
Monolith Modular Service
- Pros : La maintenance peut être simplifiée par la localisation des fonctionnalités liées dans le même dépôt, facilitant la mise à jour et le débogage.
- Cons : Des changements dans un module peuvent affecter d'autres parties du monolithe, entraînant des effets secondaires inattendus et augmentant la complexité de la maintenance.
Bounded Context Service
- Pros : Les mises à jour peuvent être gérées de manière ciblée et autonome, réduisant le risque d'effets de bord et simplifiant la maintenance.
- Cons : La nécessité de maintenir plusieurs bases de code distinctes peut augmenter l'effort global de maintenance.
Bounded Context Subservice
- Pros : La spécialisation fine du service peut conduire à une maintenance plus facile, avec des équipes dédiées qui comprennent bien leur domaine de responsabilité.
- Cons : La coordination nécessaire entre différents services partiels pour des modifications transversales peut compliquer la maintenance.
9. Résilience et Isolation des erreurs
Ce critère s'intéresse à la capacité du système à rester opérationnel en dépit des défaillances et la mesure dans laquelle un problème dans un service peut être isolé sans affecter les autres services.
Monolith Modular Service
- Pros : Les erreurs dans un module peuvent être isolées et gérées sans nécessairement impacter l'ensemble de l'application, à condition que le monolithe soit bien structuré en modules indépendants.
- Cons : En réalité, le couplage interne peut entraîner une propagation des erreurs à travers les modules, affectant la résilience globale du système.
Bounded Context Service
- Pros : Un service dédié à un Bounded Context peut assurer une isolation robuste des erreurs; un problème dans un service n'affecte pas directement les autres services.
- Cons : Si la communication entre les services n'est pas bien gérée, les erreurs peuvent quand même se propager par effet de bord via le réseau ou les données partagées.
Bounded Context Subservice
- Pros : Chaque service étant responsable d'une fraction de la fonctionnalité, une erreur est confinée à une petite partie du système, minimisant son impact global.
- Cons : La nécessité de synchroniser plusieurs services partiels pour accomplir une fonction peut complexifier la gestion des erreurs et affecter la résilience.
10. Interopérabilité et Intégration
Ce critère correspond à la capacité des services à fonctionner et à communiquer efficacement avec d'autres systèmes ou composants.
Monolith Modular Service
- Pros : L'intégration entre modules est souvent simplifiée par une communication interne, typiquement au sein d'un même processus ou machine virtuelle, ce qui peut faciliter l'interopérabilité.
- Cons : L'interopérabilité avec des systèmes externes peut être limitée par des interfaces moins flexibles, dues à la nature intégrée du monolithe.
Bounded Context Service
- Pros : Chaque service peut exposer ses propres API dédiées, souvent RESTful ou gRPC, facilitant l'intégration avec d'autres services et systèmes externes.
- Cons : Les BCS peuvent nécessiter des mécanismes d'intégration plus complexes, comme des brokers de messages ou des gateways, pour gérer les interactions entre les services.
Bounded Context Subservice
- Pros : Les services partiels peuvent se spécialiser dans des interfaces bien définies pour des tâches spécifiques, améliorant l'interopérabilité pour ces tâches.
- Cons : Nécessite une intégration soignée entre services partiels pour assurer une interaction cohérente, ce qui peut complexifier l'architecture.
11. Consistance des données
Ce critère représente la garantie que les données restent uniformes, cohérentes et précises à travers le système.
Monolith Modular Service
- Pros : La consistance est généralement assurée de manière plus aisée au sein d'un monolithe, puisque les données résident souvent dans une base de données unique, permettant des transactions atomiques et une intégrité référentielle directe.
- Cons : Les grandes bases de données monolithiques peuvent devenir un goulot d'étranglement pour les performances et la scalabilité, et peuvent complexifier les migrations et les évolutions de schéma.
Bounded Context Service
- Pros : La séparation claire des données par contexte limite les conflits et améliore la cohérence au sein de chaque microservice, avec la possibilité d'employer des modèles de données optimisés pour chaque contexte (relationnel, document, clé-valeur, ...).
- Cons : La cohérence des données entre différents BCS peut être difficile à maintenir, nécessitant des techniques comme la saga ou des transactions distribuées pour gérer la consistance.
Bounded Context Subservice
- Pros : Peut permettre une granularité de gestion des données et une spécialisation qui renforce la consistance là où elle est critique.
- Cons : La fragmentation des données peut rendre la consistance globale plus difficile à assurer sans un mécanisme de coordination adéquat.
12. Investissement en développement et temps de mise sur le marché
Ce critère évalue l'effort et les ressources nécessaires pour développer une fonctionnalité ou un système et la rapidité avec laquelle il peut être rendu disponible aux utilisateurs finaux, mettant en balance la vitesse d'exécution avec la qualité et la solidité du produit final.
Monolith Modular Service
- Pros : Les monolithes modulaires peuvent souvent être développés et déployés plus rapidement au début, car ils évitent certains des défis de distribution et de communication entre services.
- Cons : Au fil du temps, l'augmentation de la complexité peut ralentir les nouvelles fonctionnalités et les améliorations, affectant le temps de mise sur le marché et nécessitant potentiellement plus d'investissement pour maintenir et évoluer l'architecture.
Bounded Context Service
- Pros : Une fois en place, un BCS offre la possibilité de déployer rapidement de nouvelles fonctionnalités en isolation, ce qui peut accélérer la mise sur le marché pour les fonctionnalités liées à un contexte spécifique.
- Cons : La nécessité de construire et de maintenir des infrastructures de communication et de déployer des composants individuels peut initialement nécessiter un investissement plus important en temps et en ressources.
Bounded Context Subservice
- Pros : L'approche ciblée permet de développer des fonctionnalités de manière agile et de les déployer rapidement, en réduisant potentiellement les coûts initiaux.
- Cons : La coordination entre les parties d'un bounded context peut introduire des retards et nécessiter des efforts de développement supplémentaires pour assurer une intégration fluide.
13. Flexibilité et Adaptabilité
Ce critère évalue la capacité du système à évoluer et à s'adapter aux changements de besoins ou à l'environnement technique.
Monolith Modular Service
- Pros : Une bonne modularité au sein d'un monolithe peut permettre une certaine flexibilité en termes de modification et d'adaptation de modules individuels sans affecter l'ensemble du système.
- Pros : Les changements structurels majeurs peuvent être difficiles et risqués, limitant la capacité d'adaptation à long terme, en particulier dans des environnements changeants.
Bounded Context Service
- Pros : Les BCS offrent une grande flexibilité, car chaque service peut évoluer indépendamment en fonction des besoins de son contexte. Cela favorise l'adaptabilité face aux changements d'exigences ou de technologie.
- Cons : La complexité des interactions entre différents BCS peut parfois limiter la flexibilité si les interfaces entre les services ne sont pas bien conçues.
Bounded Context Subservice
- Pros : Ils permettent une adaptation rapide et flexible des fonctionnalités spécifiques sans nécessiter de modifications étendues au reste du contexte.
- Cons : Les dépendances au sein du contexte plus large peuvent restreindre la flexibilité si les autres parties du contexte ne sont pas également conçues pour être adaptables.
14. Sécurité
Ce critère est lié à la capacité du système à protéger les données et les services contre les accès non autorisés ou les attaques malveillantes.
Monolith Modular Service
- Pros : Les modules au sein d'un monolithe partagent souvent une infrastructure de sécurité commune, ce qui peut simplifier la gestion des politiques de sécurité et des accès.
- Cons : Une faille de sécurité dans une partie du monolithe peut potentiellement compromettre l'ensemble du système, augmentant le risque de failles de sécurité à grande échelle.
Bounded Context Service
- Pros : Chaque BCS peut implémenter des mécanismes de sécurité adaptés à ses propres exigences, ce qui peut renforcer la sécurité en cas de conception appropriée.
- Cons : La gestion de la sécurité peut devenir plus complexe en raison du besoin de maintenir des politiques cohérentes et de sécuriser les communications entre services.
Bounded Context Subservice
- Pros : La focalisation sur une partie spécifique du contexte permet de resserrer les contrôles de sécurité autour de fonctionnalités critiques, potentiellement en améliorant la posture de sécurité de ces composants.
- Cons : Si le service ne bénéficie pas de la même attention en matière de sécurité que le reste du contexte, il peut devenir un maillon faible.
15. Connaissance et Compétences de l'équipe
Ce critère s'attache au niveau d'expertise nécessaire pour construire, déployer, et maintenir l'architecture.
Monolith Modular Service
- Pros : L'équipe peut se spécialiser sur un ensemble de technologies communes et développer une compréhension profonde du système entier, ce qui facilite le partage des connaissances et le travail en équipe.
-Cons : La nécessité de comprendre un grand système dans son intégralité peut être accablante pour les nouveaux membres de l'équipe et exiger des compétences étendues.
Bounded Context Service
- Pros : Les équipes peuvent se concentrer sur un domaine spécifique, ce qui réduit la charge cognitive et permet d'acquérir une expertise approfondie dans ce domaine.
- Cons : Des connaissances spécialisées peuvent créer des silos au sein de l'organisation si elles ne sont pas bien gérées, et la collaboration inter-équipes peut être entravée.
Bounded Context Subservice
- Pros : Les membres de l'équipe peuvent se spécialiser encore plus sur des aspects spécifiques du contexte, ce qui favorise l'expertise et l'efficacité dans ces domaines.
- Cons : Il peut y avoir un risque de perte de connaissance si l'équipe est trop spécialisée et que certains membres quittent l'équipe.
16. Réutilisation de composants
Ce critère concernen la facilité avec laquelle les parties du système peuvent être réutilisées dans différents contextes ou projets.
Monolith Modular Service
- Pros : La réutilisation est simplifiée au sein d'un même codebase monolithique, ce qui peut réduire le temps de développement et maintenir la cohérence.
- Cons : Trop de réutilisation interne peut conduire à un couplage inapproprié entre les modules, rendant difficile la modification et l'évolution du code.
Bounded Context Service
- Pros : Encourage la réutilisation de composants de haut niveau qui sont spécifiques à un contexte donné, améliorant ainsi l'alignement avec le modèle.
- Cons : La réutilisation entre différents BCS peut être plus complexe en raison de la nécessité de maintenir l'autonomie et la cohérence de chaque contexte.
Bounded Context Subservice
- Pros : Favorise la réutilisation fine de fonctionnalités spécifiques, ce qui peut améliorer l'efficacité du développement pour des besoins récurrents au sein d'un même contexte.
- Cons : Peut entraver la réutilisation au-delà des frontières du contexte et conduire à une duplication si les composants ne sont pas conçus pour être partagés.
17. Gouvernance et Conformité
Ce critèrem mesure de la capacité à maintenir des normes de qualité, suivre les politiques internes et répondre aux exigences légales ou réglementaires.
Monolith Modular Service
- Pros : La gouvernance peut être plus facilement imposée car il y a un seul pipeline de déploiement et une base de code commune, facilitant l'audit et le respect des normes.
- Cons : Des changements dans les réglementations ou les politiques de conformité peuvent nécessiter des modifications à grande échelle, affectant potentiellement de nombreux modules à la fois.
Bounded Context Service
- Pros : Chaque BCS peut être géré et conformé individuellement, permettant une gouvernance précise et des ajustements rapides aux changements réglementaires spécifiques à chaque contexte.
- Cons : Nécessite une gouvernance plus distribuée et des mécanismes de contrôle qui peuvent être complexes à mettre en œuvre et à maintenir entre différents services.
Bounded Context Subservice
- Pros : Permet de cibler la gouvernance sur des fonctionnalités spécifiques, réduisant ainsi la portée et la complexité de la mise en conformité.
- Cons : Peut entraîner des défis dans l'application uniforme de la gouvernance et de la conformité au sein d'un contexte, surtout si les services sont fortement distribués.
Conclusion
Construire une architecture à la fois robuste et évolutive est un exercice d'équilibre délicat, qui requiert non seulement une solide compréhension des besoins fonctionnels mais aussi une maîtrise approfondie des aspects techniques. Trop de projets architecturaux ont échoué, victimes soit d'une obsession pour la technicité au détriment d'une conception efficace et alignée sur les objectifs métier, soit d'une vision trop idéaliste des exigences fonctionnelles, sous-estimant les défis techniques. À cela s'ajoute la tendance au « Cargo Cult », où l'adoption non critique des dernières technologies à la mode peut mener à des choix architecturaux inappropriés. Un exemple flagrant en est la transformation malavisée de 'Monolithic Big Ball of Mud' en Distributed Big Ball of Mud, où la mécompréhension des principes sous-jacents des microservices amplifie plutôt que résout les problématiques d'architecture initiales.
Nous avons vu à travers les divers articles et présentations mentionnés dans ce texte, l'importance cruciale du bounded context dans l'élaboration d'une architecture logicielle robuste. De Bounded Context vs Micro-services à Model Mitosis, en passant par Hexagonal at Scale, l'accent a été mis sur la nécessité d'un découpage méticuleux et réfléchi pour éviter les écueils d'une structure mal conçue. Ces références sont fondamentales pour quiconque cherche à concevoir et à découper son architecture en alignement avec les principes directeurs du Domain-Driven Design.
La topologie des services de domaine se présente comme un outil supplémentaire, peut-être de nature plus technique, mais intrinsèquement lié au découpage en bounded contexts. Elle enrichit l'arsenal des développeurs en fournissant des heuristiques précises pour peaufiner le découpage des services. Ainsi, elle vise à affiner l'adéquation entre la structure technique et les contours fonctionnels des domaines, facilitant la construction d'une architecture à la fois robuste et évolutive.
Cependant, il est essentiel de reconnaître que la finesse de ce découpage doit être ajustée avec précaution. Un découpage trop fin, menant à une profusion de microservices, peut entraîner une complexité opérationnelle qui surpasse les bénéfices de modularité. En revanche, une architecture monolithique modulaire, correctement divisée selon les lignes des bounded contexts, peut offrir une excellente balance entre la cohésion du domaine et la simplicité opérationnelle.
En choisissant soigneusement le niveau de granularité de nos services, en évitant une fragmentation excessive, nous pouvons jouir des avantages structurels de l'approche DDD sans tomber dans les pièges d'une complexité opérationnelle et d'infrastructure inutile. Les plateformes cloud jouent un rôle de soutien dans ce processus, en allégeant la charge de l'infrastructure, mais elles ne remplacent pas la nécessité d'une expertise technique pointue.
Ainsi, alors que nous explorons les avantages de l'alignement entre les bounded contexts de DDD et la topologie des services de domaine, il est impératif de conserver une vision claire des implications pratiques et des coûts. Il est crucial d'équilibrer les gains architecturaux avec la capacité opérationnelle réelle de nos équipes, afin que l'élégance de la conception ne soit pas occultée par une complexité opérationnelle disproportionnée.
En fin de compte, ces décisions architecturales doivent être prises avec discernement, en tenant compte également de la maturité de l'organisation et de son aptitude à naviguer dans le paysage exigeant des architectures distribuées.
Et surtout assurez-vous d'avoir bien pris note de vos décisions dans un Architecture Decision Record !
