Type de processus
Expression graphique
Type de réflexion
Expression structurée
Type de note
Expression efficace
Carte arborescente
Diagramme de parenthèses
Mode par défaut
En développement logiciel , un défi constant se pose : plus la logique métier se complexifie, plus le code devient difficile à maintenir. Les premières applications CRUD basées sur l’architecture MVC fonctionnent bien, mais à mesure que les besoins métier évoluent, les équipes de développement se retrouvent rapidement face à un dilemme : « Où placer la logique métier ? »
La conception pilotée par le domaine (DDD) a été créée pour résoudre ce problème. Proposée par le gourou du logiciel Eric Evans en 2003, elle vise à construire des modèles logiciels parfaitement alignés sur les besoins métiers en utilisant la connaissance du domaine métier comme moteur principal de la conception du système. La DDD n'est pas un style architectural spécifique, mais une méthodologie de conception complète et systématique qui simplifie les domaines métiers complexes grâce à la délimitation de leurs frontières, nous aidant ainsi à définir clairement les limites du domaine et de l'application.
Cet article explique en détail les concepts fondamentaux, la conception stratégique et tactique, ainsi que l'architecture en couches du DDD . Que vous soyez un développeur débutant en DDD, un chef de produit ou un architecte souhaitant perfectionner vos compétences en conception d'architecture, vous y trouverez l'inspiration.
Dans les modèles de développement traditionnels, la logique métier est souvent imbriquée dans les opérations de base de données et les fonctionnalités du framework, ce qui nuit à la lisibilité du code et engendre des coûts de maintenance élevés. L'idée centrale du DDD est de séparer complètement la logique métier pure de l'implémentation technique, permettant ainsi aux développeurs de penser comme des experts métier.
Le principe fondamental du DDD est d'établir un langage universel. Tous les acteurs – développeurs, testeurs, chefs de produit et experts métier – doivent utiliser un langage commun unifié, basé sur un modèle de domaine. Cela signifie que les noms de classes et de méthodes dans le code doivent refléter directement les concepts métier, plutôt que des termes vagues comme « DataProcessor » ou « Manager ». Par exemple, un système de commerce électronique devrait avoir une classe « Order » et sa méthode « place() », au lieu d'un service générique « OrderService » qui regroupe toute la logique.
Le deuxième concept fondamental du DDD est de se concentrer sur le domaine principal. Dans un système d'entreprise complexe, les différents sous-domaines ont des valeurs métier distinctes. Le domaine principal est un facteur clé de succès et exige le plus d'efforts de conception ; le domaine commun correspond aux fonctionnalités partagées par plusieurs sous-domaines ; et le domaine de support représente l'infrastructure qui prend en charge les autres sous-domaines.
La pratique du DDD comporte deux dimensions : la conception stratégique et la conception tactique. La conception stratégique se concentre sur la division du domaine et la définition des limites, résolvant le problème « quoi faire » ; la conception tactique se concentre sur l’implémentation spécifique du code, résolvant le problème « comment le faire ».
Processus de conception axé sur le domaine
Face à un système de grande envergure, il est illusoire de vouloir couvrir tous les domaines d'activité avec un modèle unique. La partie « conception stratégique » du DDD fournit des outils puissants pour le partitionnement des systèmes complexes.
Un domaine désigne le problème qu'une entreprise doit résoudre. Prenons l'exemple d' un système de gestion de communauté de contenu : la « communauté de contenu » dans son ensemble constitue un domaine, qui peut être décomposé en plusieurs sous-domaines tels que la gestion des utilisateurs , les lecteurs , le paiement et la communauté . Parmi ceux-ci, la communauté peut appartenir au domaine principal, tandis que le paiement relève du domaine de support.
Point clé à retenir : en matière de conception stratégique, il est important d’identifier les sous-domaines qui constituent les compétences clés de l’entreprise et de concentrer les ressources sur ceux-ci.
Diagramme de sous-domaine de la communauté de contenu DDD
Il s'agit du schéma stratégique le plus important en DDD (Data Demand and Decision Making). Il définit clairement le périmètre d'application d'un modèle, c'est-à-dire : « Quelles sont les limites de ce terme ? » Par exemple, dans le contexte du commerce électronique, le terme « produit » possède des attributs tels que le prix, la description et la catégorie ; tandis que dans le contexte de la logistique, il se concentre davantage sur le poids et le volume.
Chaque contexte délimité constitue une « frontière sémantique » indépendante, dotée d'un langage et d'un modèle de domaine communs et unifiés. Le système est ainsi décomposé en plusieurs modules très cohérents et faiblement couplés.
Principe clé : Les contextes délimités clarifient leur relation avec d'autres contextes grâce à la cartographie contextuelle, évitant ainsi la pollution du modèle.
[Modélisation de la stratégie DDD] - Délimitation des contextes délimités
L'analyse des dépendances des données (DDD) et l'architecture de microservices sont parfaitement complémentaires. Un contexte délimité bien conçu est un candidat idéal pour un microservice. À l'inverse, une segmentation aveugle d'un système en couches techniques peut facilement aboutir à un monolithe distribué : les services peuvent être séparés, mais le couplage persiste. Dans une architecture de microservices, un service ne doit pas être plus petit qu'un agrégat ni plus grand qu'un contexte délimité.
Dans ce contexte délimité, DDD fournit une suite d'outils de modélisation tactique pour la construction de modèles de domaine.
Une entité est un objet doté d'un identifiant unique et d'un cycle de vie. Par exemple, même si un utilisateur change de nom, son identifiant unique reste inchangé et il demeure la même entité. Les entités utilisent généralement un modèle de richesse, où les comportements métier sont encapsulés au sein de l'entité.
Les objets valeur ne possèdent pas d'identifiants uniques et se distinguent uniquement par leurs attributs. Ils sont généralement immuables. Par exemple, le montant (Argent) est déterminé par la devise et la valeur ; deux objets Argent de même montant et de même devise sont interchangeables. Une utilisation appropriée des objets valeur permet de réduire la complexité du système ; par exemple, les adresses postales, les adresses électroniques et les numéros de téléphone peuvent tous être modélisés comme des objets valeur.
Une agrégation est un ensemble d'entités et d'objets de valeur liés, gérés comme un tout. L'entité racine de l'agrégation est l'entité centrale qui garantit la cohérence au sein de celle-ci. Par exemple, l'entité racine de l'agrégation « Commande » gère les entités « Article de commande » et « Paiement » ; tout accès aux articles de commande doit se faire via l'entité « Commande ».
Principes de conception des agrégats : les transactions au sein d’un même agrégat doivent rester cohérentes ; les références à d’autres agrégats doivent se faire uniquement par le biais d’identifiants, en évitant les références directes entre agrégats. Les agrégats doivent être conçus pour être aussi petits que possible.
Il s'agit d'un concept souvent source de confusion pour les débutants. Les services de domaine exécutent des comportements spécifiques au domaine qui ne peuvent être attribués à des entités ou à des objets de valeur. Ils appartiennent à la couche domaine, préservent la pureté du domaine et ne nécessitent aucune intervention technique. Par exemple, le service TransferService gère les virements entre comptes ; il n'est rattaché à aucune entité de compte particulière, mais constitue une logique métier essentielle.
Les services applicatifs coordonnent les objets et services de domaine, gèrent les flux de travail applicatifs et appartiennent à la couche application. Sans état, ils sont responsables de la planification des cas d'utilisation, de la gestion des transactions et de l'authentification de sécurité, mais ne contiennent pas de règles métier.
Le dépôt sert de pont entre la couche métier et la couche infrastructure. Il est défini dans la couche métier comme une interface abstraite, tandis que la couche infrastructure implémente la logique de stockage spécifique. Le dépôt expose uniquement des méthodes d'accès par agrégation et ne dévoile aucun détail ORM.
Les événements de domaine sont des événements métier significatifs qui se produisent au sein d'un domaine et qui peuvent être utilisés pour déclencher une logique métier ultérieure et découpler les modules.
Diagramme de conception tactique piloté par le domaine (DDD) du blog
DDD recommande une architecture en couches, généralement composée de quatre couches : couche d’interface utilisateur, couche applicative, couche de domaine et couche d’infrastructure.
Ce composant assure l'interaction avec les utilisateurs, la réception des requêtes et le renvoi des réponses. Dans une application web, il correspond au contrôleur, mais se limite à la validation des paramètres et à la mise en forme des résultats ; il ne contient aucune logique métier.
Les objets du domaine sont coordonnés pour répondre aux cas d'utilisation métier, en gérant les limites des transactions, la sécurité et l'authentification. Les services de la couche application restent sans état, se contentant d'appeler les services du domaine ou les méthodes racines agrégées, et ne contiennent aucune règle métier.
Le cœur du DDD englobe toutes les règles et tous les modèles métier. Il définit les racines agrégées, les entités, les objets de valeur et les services de domaine afin de garantir l'intégrité de la logique métier.
Elle assure le support technique, notamment pour l'accès aux bases de données, les files d'attente de messages et les appels d'API externes. Grâce au principe d'inversion des dépendances, la couche métier définit les interfaces et la couche infrastructure les implémente, garantissant ainsi une isolation complète entre la logique métier et l'implémentation technique.
Dans une architecture en couches DDD, les dépendances sont orientées de l'extérieur vers l'intérieur : la couche d'interface utilisateur dépend de la couche application, la couche application dépend de la couche métier, et l'interface de la couche infrastructure est définie par la couche métier grâce à l'inversion des dépendances. La couche métier est indépendante de tout framework ou technologie spécifique, ce qui permet de remplacer la logique métier principale par d'autres technologies sans modification.
Dans la mise en œuvre pratique de la conception pilotée par le domaine (DDD), la visualisation est une étape cruciale pour faciliter la recherche de consensus au sein des équipes. Qu'il s'agisse de la délimitation du contexte lors de la phase de conception stratégique ou de la construction du modèle de domaine lors de la phase de conception tactique, des diagrammes clairs sont indispensables. ProcessOn, outil professionnel de création de diagrammes en ligne, permet de visualiser efficacement l'ensemble du processus des architectures DDD.
1. Rendez-vous sur votre page de profil ProcessOn et créez un « diagramme de flux », ou recherchez des mots clés tels que « conception d'architecture DDD » dans la communauté des modèles.
2. À gauche, sous « Plus de graphiques », vous pouvez sélectionner des catégories de graphiques, comme des organigrammes et des diagrammes UML, à ajouter à la bibliothèque graphique. Glissez-déposez des formes, telles que des rectangles et des cercles, depuis la bibliothèque graphique vers la zone de dessin, et utilisez des flèches pour relier différents éléments et exprimer leurs dépendances.
3. Lorsqu'un ou plusieurs éléments sont sélectionnés, la barre d'outils supérieure peut utiliser différentes couleurs pour distinguer les différents niveaux du modèle, ainsi que pour effectuer des ajustements de mise en page tels que l'alignement graphique et les paramètres de calque.
4. Une fois le diagramme terminé, vous pouvez cliquer sur le bouton de partage collaboratif en haut à droite pour partager le diagramme d'architecture DDD avec vos collègues ou clients afin de poursuivre l'amélioration du modèle. Vous pouvez également l'exporter au format image haute résolution, PDF, SVG ou autres formats pour consultation ultérieure.
La conception pilotée par le domaine ne se limite pas à un ensemble de modèles techniques ou de spécifications architecturales ; elle représente une révolution dans la façon de penser et une méthodologie systématique pour appréhender la complexité intrinsèque des logiciels. Elle nous enseigne que le développement logiciel ne commence pas par la création de tableaux, mais par la compréhension du métier.
En définissant stratégiquement les limites du domaine et en concevant de manière tactique un modèle de domaine hautement cohérent, combinés à une architecture en couches pour isoler la logique métier de l'implémentation technique, le DDD peut améliorer considérablement la maintenabilité et la scalabilité des systèmes d'entreprise complexes. À l'ère des microservices, la méthode de partitionnement du contexte délimité proposée par le DDD constitue la meilleure pratique pour décomposer scientifiquement les microservices.
Organigramme de carte mentale collaborative en ligne gratuit
