REL03-BP02 Créer des services axés sur des domaines d’activité et la fonctionnalité
Une architecture orientée services (SOA) définit des services avec des fonctions bien déterminées dictées par les besoins métier. Les microservices utilisent des modèles de domaine et un contexte limité pour définir les limites des services en fonction des limites du contexte métier. En se concentrant sur les domaines d’activité et les fonctionnalités, les équipes peuvent définir des exigences de fiabilité indépendantes pour leurs services. Les contextes limités isolent et encapsulent la logique métier, ce qui permet aux équipes de mieux raisonner sur la manière de gérer les défaillances.
Résultat désiré : les ingénieurs et les parties prenantes de l’entreprise définissent conjointement des contextes délimités et les utilisent pour concevoir des systèmes en tant que services remplissant des fonctions commerciales spécifiques. Ces équipes utilisent des pratiques établies telles que l’event storming pour définir les exigences. Les nouvelles applications sont conçues comme des services dont les limites sont bien définies et qui possèdent un couplage faible. Les monolithes existants sont décomposés en contextes délimités
Les services orientés domaine sont exécutés sous la forme d’un ou de plusieurs processus qui ne partagent pas d’état. Ils répondent de manière indépendante aux fluctuations de la demande et gèrent les scénarios de panne à la lumière des exigences spécifiques du domaine.
Anti-modèles courants :
-
Les équipes sont constituées autour de domaines techniques spécifiques tels que l’interface utilisateur et l’expérience utilisateur, les intergiciels ou les bases de données plutôt que de domaines commerciaux spécifiques.
-
Les applications couvrent des responsabilités de domaine. Les services qui couvrent des contextes limités peuvent être plus difficiles à gérer, nécessiter des efforts de test plus importants et nécessiter la participation de plusieurs équipes de domaine aux mises à jour logicielles.
-
Les dépendances de domaine, telles que les bibliothèques d’entités de domaine, sont partagées entre les services de telle sorte que les modifications apportées à un domaine de service nécessitent des modifications apportées à d’autres domaines de service
-
Les contrats de service et la logique métier n’expriment pas les entités dans un langage de domaine commun et cohérent, ce qui crée des couches de traduction qui compliquent les systèmes et augmentent les efforts de débogage.
Avantages du respect de cette bonne pratique : les applications sont conçues comme des services indépendants délimités par domaines d’activité et utilisent un langage métier commun. Les services peuvent être testés et déployés indépendamment. Les services répondent aux exigences de résilience spécifiques au domaine mis en œuvre.
Niveau d’exposition au risque si cette bonne pratique n’est pas respectée : élevé
Directives d’implémentation
La conception pilotée par domaine (DDD) est l’approche fondamentale de la conception et de la création de logiciels autour de domaines métier. Il est utile de travailler avec un cadre existant lorsque vous créez des services axés sur des domaines métier. Lorsque vous travaillez avec des applications monolithiques existantes, vous pouvez tirer parti des modèles de décomposition qui fournissent des techniques éprouvées pour moderniser les applications en services.
Conception pilotée par domaine
Étapes d’implémentation
-
Les équipes peuvent organiser des ateliers event storming
pour identifier rapidement les événements, les commandes, les agrégats et les domaines dans un format léger de notes autocollantes. -
Une fois que les entités et les fonctions de domaine ont été formées dans un contexte de domaine, vous pouvez diviser votre domaine en services à l’aide d’un contexte délimité
, dans lequel les entités partageant des caractéristiques et des attributs similaires sont regroupées. La division en contextes permet de faire émerger un modèle de délimitation des microservices. -
Par exemple, les entités du site Amazon.com peuvent inclure le colis, la livraison, le calendrier, le prix, la remise et la devise.
-
Le colis, la livraison et le calendrier sont regroupés dans le contexte d’expédition, tandis que le prix, la remise et la devise sont regroupés dans le contexte de tarification.
-
-
Décomposition des monolithes en microservices décrit les modèles de refactorisation des microservices. L’utilisation de modèles de décomposition par capacité métier, sous-domaine ou transaction s’inscrit parfaitement dans les approches axées sur le domaine.
-
Les techniques tactiques telles que le contexte à bulles
vous permettent d’introduire le DDD dans des applications existantes ou héritées sans devoir procéder à des réécritures préalables et sans engagement total envers le DDD. Dans une approche basée sur un contexte à bulles, un petit contexte délimité est établi à l’aide d’une cartographie et d’une coordination des services, ou couche anticorruption , qui protège le modèle de domaine nouvellement défini des influences extérieures.
Une fois que les équipes ont effectué une analyse du domaine et défini des entités et des contrats de service, elles peuvent tirer parti des services AWS pour mettre en œuvre leur conception axée sur le domaine sous forme de services basés sur le cloud.
-
Commencez votre développement en définissant des tests qui appliquent les règles métier de votre domaine. Le développement piloté par les tests (TDD) et le développement piloté par le comportement (BDD) aident les équipes à concentrer leurs services sur la résolution des problèmes commerciaux.
-
Sélectionnez les services AWS
qui répondent le mieux aux exigences de votre domaine d’activité et à votre architecture de microservices : -
AWS sans serveur
permet à votre équipe de se concentrer sur une logique de domaine spécifique au lieu de gérer les serveurs et l’infrastructure. -
Les conteneurs AWS
simplifient la gestion de votre infrastructure afin que vous puissiez vous concentrer sur les exigences de votre domaine. -
Les bases de données sur mesure
vous permettent d’adapter les exigences de votre domaine au type de base de données le mieux adapté.
-
-
Création d’architectures hexagonales sur AWS décrit un cadre permettant d’intégrer une logique métier à des services en procédant de manière rétroactive à partir d’un domaine métier afin de répondre à des exigences fonctionnelles, puis d’associer des adaptateurs d’intégration. Les modèles qui séparent les détails de l’interface de la logique métier avec les services AWS aident les équipes à se concentrer sur les fonctionnalités du domaine et à améliorer la qualité des logiciels.
Ressources
Bonnes pratiques associées :
Documents connexes :
Exemples connexes :
Outils associés :
