urbanisation-si.com

Nous allons décrire dans cet article le rôle des différentes couches de l'Architecture Microservices et le lien avec la méthode de conception DDD.

(Ce diagramme ArchiMate, montre que toutes les couches dépendent de la couche “Domaine Métier”. Réalisé avec Modelio Open Source outil de modélisation UML, BPMN et ArchiMate)

Certaines grandes plateformes numériques dont certaines font partie des GAFAM ont été confrontées récemment à de gigantesques pannes paralysant l’ensemble de leurs activités écornant leur image de Graal de la technologie. Un des enjeux de l’architecture Microservices est d’offrir une meilleure résilience grâce à des outils de détection, de contournement et de remplacement des blocs défectueux. 

Si la physique de l’infiniment grand et de l’infiniment petit forme un tout, il en va de même pour les Systèmes d’Information qui se basent sur les concepts et patterns des technologies objets de développement, comme les fameux Design Patterns du GoF (1995), les principes SOLID, les GRASP patterns, ceux de Martin Fowler et Sam Newman.

Les systèmes sont faiblement couplés vers l’extérieur et sont constitués d’éléments cohérents en interne.

On est bien en présence d'une architecture fractale. Les domaines d'application des fractales se retrouvent partout même dans l'urbanisme des villes et donc aussi dans l'urbanisme des SI.

Dans sa méthode de conception DDD, Eric Evans, auteur du livre “Domain-Driven Design: Tackling Complexity in the Heart of Software”, intègre et développe ces patterns dans l'Architecture Microservices adoptée aussi bien par les GAFAM que par les PME.  

Couche Contrôleur

Les interfaces de communication ou API (Application Program Interface) sont implémentées.

Le protocole le plus simple et le plus utilisé est REST (REpresentational State Transfer) reposant sur HTTP.

Les données sont représentées textuellement en JSON (JavaScript Object Notation).

Tout est permis, on peut trouver des protocoles de type “Event Streaming Consumer” ou des interfaces pour les programmes batchs. 

Le pattern d’architecture distribuée DTO (Data Transfer Object), consistant à ne transférer que les données utiles est mis en œuvre et s’appuie sur des technologies de sérialisation/désérialisation des objets en JSON.

L'implémentation du pattern "proxy" permet d'utiliser des objets distants et complexes comme s'ils étaient locaux en masquant la gestion des trames HTTP et la transformation en JSON.
Pour les spécificités des microservices, les aspects comme la traçabilité condition sine qua non pour la mise au point, la supervision des états, la conformité des SLA (Service Level Agreement) et l’administration sont effectués par de nombreuses technologies faisant partie de l’entité contrôleur.  

Couche Applicative

Les fonctionnalités sont dérivées des cas d’utilisation UML dans lesquels on trouve des VO (Value Object) qui sont des objets immutables.
La coordination et les transactions longues métier sont réalisées par la gestion de l’état de progression d’un processus métier.
Aucune règle métier n’est exécutée, seuls des contrôles syntaxiques sont opérés pour préparer les données métier pour la couche “Domaine Métier”.
Les authentifications, autorisations, cryptages et les parades aux attaques connues, sont mis en œuvre.
Des contributions à l’amélioration des performances peuvent se traduire par des technologies de cache.

Couche Domaine Métier (DDD)

Ce niveau représente une zone métier (“Bounded context” en DDD) bien délimitée et autonome (“Les bonnes barrières font les bons voisins” Eric Evans).
En MDA (Model Driven Architecture), ce serait la couche PIM (Platform Independent Model).

Ici, on ne trouve pas la moindre trace de framework technologique, la persistance par exemple est reléguée dans l’infrastructure.

A l’intérieur des frontières, on parle le jargon des experts métiers (traduit en DDD cela donne : “Ubiquitous Language”). Le langage ubiquitaire est le concept de définition d'un langage (parlé et écrit) qui est également utilisé par les développeurs et les experts du domaine pour éviter les incohérences et les problèmes de communication dus aux problèmes de traduction et aux malentendus. La même terminologie apparaît dans le code, les conversations entre tous les membres de l’équipe, les spécifications fonctionnelles, etc.
Les modèles sont composés de diagrammes de classes et d’états-transitions UML.
Le métier et le code sont alors liés par l’Ubiquitous Language.

Pour faire communiquer des "bounded context" différents, il faut des adaptateurs permettant l’interopérabilité et garantissant l’indépendance des systèmes. Déjà en 1995 la bande des quatre (Erich Gamma, Richard Helm, Ralph Johnson et John Vlisside) inventeurs des patterns de conception objet et auteurs du livre fondateur “Design Patterns: Elements of Reusable Object-Oriented Software” avaient défini le pattern “adapter”.

Oserait-on l’heuristique : DDD = 80% de bounded context + 20% d’adapter.

Couche Infrastructure

Elle sert de support à toutes les autres couches rendant possible l’interopérabilité.
La persistance des entités métier est réalisée. 
Les autres couches y accèdent en utilisant l’injection de dépendances (pattern IOC Inverse Of control) qui est un des principes SOLID (Single responsibility ; Open closed ; Liskov substitution ; Interface segregation ; Dependency inversion), qui délègue à un tiers la réalisation des relations entre les entités permettant l'agilité, l'évolutivité, la maintenabilité et la réutilisabilité en maintenant un couplage faible entre les composants.

Conclusion

Le domaine ne dépend d’aucune couche
L’infrastructure dépend du domaine.
L’application dépend du domaine
La présentation dépend de l’application et de l’infrastructure.

“Tiny, the only thing you need to know about development, project management and leadership” 
Chad Fowler
(“Minuscule, la seule chose que vous devez savoir sur le développement, la gestion de projet et le leadership”)

Compléments de lecture

• L’Architecture Micro-Services expliquée à ma fille
  
  
• Inconvénients de l'Architecture Micro-Services
  
  
• Orchestration des micro-services avec BPMN
  
  
• Conseils pour réussir vos micro-services et éviter qu’ils ne se transforment en véritable pensum
  
  
• Estimation de la complexité d’une Architecture Micro-Services
  
  
• Solutions sur étagère pour la gestion des défaillances des Micro-Services
  
  
• Comment éviter la loi de Conway et faciliter ainsi l’agilité avec l’approche Micro-Services ?
  
  
• Le meilleur outil pour transformer, dériver, parcourir, requêter sur des modèles afin de mettre en œuvre MDA (Model Driven Architecture)