Présentation - AWS Conseils prescriptifs

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Présentation

Conception pilotée par domaine (DDD)

Dans la conception pilotée par domaine (DDD), un domaine est au cœur du système logiciel. Le modèle de domaine est défini en premier, avant que vous ne développiez un autre module, et il ne dépend pas des autres modules de bas niveau. Au contraire, les modules tels que les bases de données, la couche de présentation et les API externes dépendent tous du domaine.

Dans DDD, les architectes décomposent la solution en contextes limités en utilisant une décomposition basée sur la logique métier au lieu d'une décomposition technique. Les avantages de cette approche sont abordés dans laRésultats commerciaux ciblés section.

Le DDD est plus facile à mettre en œuvre lorsque les équipes utilisent une architecture hexagonale. Dans l'architecture hexagonale, le cœur de l'application est le centre de l'application. Il est découplé des autres modules via des ports et des adaptateurs, et ne dépend pas des autres modules. Cela correspond parfaitement à DDD, où un domaine est au cœur de l'application qui résout un problème commercial. Ce guide propose une approche dans laquelle vous modélisez le cœur de l'architecture hexagonale en tant que modèle de domaine d'un contexte borné. La section suivante décrit plus en détail l'architecture hexagonale.

Ce guide ne couvre pas tous les aspects du DDD, qui est un sujet très vaste. Pour mieux comprendre, vous pouvez consulter les ressources DDD répertoriées sur le site Web Domain Language.

Architecture hexagonale

L'architecture hexagonale, également appelée ports et adaptateurs ou architecture onion, est un principe de gestion de l'inversion des dépendances dans les projets logiciels. L'architecture hexagonale met fortement l'accent sur la logique métier du domaine de base lors du développement de logiciels et traite les points d'intégration externes comme secondaires. L'architecture hexagonale aide les ingénieurs logiciels à adopter de bonnes pratiques telles que le développement piloté par les tests (TDD), qui, à son tour, favorise l'évolution de l'architecture et vous aide à gérer des domaines complexes sur le long terme.

Comparons l'architecture hexagonale à l'architecture stratifiée classique, qui est le choix le plus populaire pour la modélisation de projets logiciels structurés. Il existe des différences subtiles mais importantes entre les deux approches.

Dans l'architecture en couches, les projets logiciels sont structurés en niveaux, ce qui représente des préoccupations générales telles que la logique métier ou la logique de présentation. Cette architecture utilise une hiérarchie de dépendances, dans laquelle les couches supérieures dépendent des couches situées en dessous, mais pas l'inverse. Dans le diagramme suivant, la couche de présentation est responsable des interactions utilisateur. Elle inclut donc l'interface utilisateur, les API, les interfaces de ligne de commande et des composants similaires. La couche de présentation dépend de la couche métier, qui implémente la logique de domaine. La couche métier, quant à elle, dépend de la couche d'accès aux données et de plusieurs services externes.

Architecture en couches classique

Le principal inconvénient de cette configuration est la structure de dépendance. Par exemple, si le modèle de stockage des données dans la base de données change, cela affecte l'interface d'accès aux données. Toute modification apportée au modèle de données affecte également la couche métier, qui dépend de l'interface d'accès aux données. Par conséquent, les ingénieurs logiciels ne peuvent apporter aucune modification à l'infrastructure sans affecter la logique du domaine. Ceci, à son tour, augmente la probabilité de bogues de régression.

L'architecture hexagonale définit les relations de dépendance d'une manière différente, comme illustré dans le diagramme suivant. Il concentre la prise de décision autour de la logique métier du domaine, qui définit toutes les interfaces. Les composants externes interagissent avec la logique métier par le biais d'interfaces appelées ports. Les ports sont des abstractions qui définissent les interactions du domaine avec le monde extérieur. Chaque composant de l'infrastructure doit implémenter ces ports, afin que les modifications apportées à ces composants n'affectent plus la logique du domaine principal.

Architecture hexagonale

Les composants environnants sont appelés adaptateurs. Un adaptateur est un proxy entre le monde extérieur et le monde interne et implémente un port défini dans le domaine. Les adaptateurs peuvent être classés en deux groupes : principaux et secondaires. Les adaptateurs principaux sont les points d'entrée du composant logiciel. Ils permettent aux acteurs externes, aux utilisateurs et aux services d'interagir avec la logique de base. AWS Lambdaest un bon exemple d'adaptateur principal. Il s'intègre à plusieursAWS services qui peuvent invoquer les fonctions Lambda comme points d'entrée. Les adaptateurs secondaires sont des wrappers de bibliothèque de services externes qui gèrent les communications avec le monde extérieur. Un client Amazon DynamoDB pour l'accès aux données est un bon exemple d'adaptateur secondaire.

Résultats commerciaux ciblés

L'architecture hexagonale décrite dans ce guide vous aide à atteindre les objectifs suivants :

Ces processus sont présentés en détail dans les sections suivantes.