Conception axée sur le domaine - Domain-driven design

Conception pilotée par le domaine ( DDD ) est le concept que la structure et le langage du code logiciel (noms de classe, les méthodes de classe , les variables de classe ) doivent correspondre au domaine des affaires . Par exemple, si un logiciel traite les demandes de prêt, il peut avoir des classes telles que LoanApplication et Customer, et des méthodes telles que AcceptOffer et Withdraw.

DDD relie la mise en œuvre à un modèle évolutif.

La conception axée sur le domaine repose sur les objectifs suivants :

placer l'accent principal du projet sur le domaine principal et la logique du domaine ;
baser des conceptions complexes sur un modèle du domaine ;
initier une collaboration créative entre les experts techniques et les experts du domaine pour affiner de manière itérative un modèle conceptuel qui aborde des problèmes de domaine particuliers.

Les critiques de la conception axée sur le domaine soutiennent que les développeurs doivent généralement implémenter beaucoup d'isolation et d'encapsulation pour maintenir le modèle en tant que construction pure et utile. Alors que la conception axée sur le domaine offre des avantages tels que la maintenabilité, Microsoft la recommande uniquement pour les domaines complexes où le modèle offre des avantages clairs dans la formulation d'une compréhension commune du domaine.

Le terme a été inventé par Eric Evans dans son livre du même titre publié en 2003.

Aperçu

La conception axée sur le domaine articule un certain nombre de concepts et de pratiques de haut niveau.

Le domaine est d'une importance primordiale , le domaine auquel l'utilisateur applique un programme est le domaine du logiciel. Le domaine d'un logiciel régit son contexte , le cadre dans lequel un mot ou une déclaration apparaît qui détermine sa signification. À partir de là, les développeurs construisent un modèle de domaine : un système d'abstractions qui décrit des aspects sélectionnés d'un domaine et peut être utilisé pour résoudre des problèmes liés à ce domaine.

Ces aspects de la conception axée sur le domaine visent à favoriser un langage omniprésent, ce qui signifie que le modèle de domaine doit former un langage commun partagé par les experts du domaine pour décrire les exigences du système, les utilisateurs professionnels, les sponsors et les développeurs.

Dans la conception axée sur le domaine , la couche de domaine est l'une des couches communes d'une architecture multicouche orientée objet .

Types de modèles

La conception axée sur le domaine reconnaît plusieurs types de modèles.

Par exemple, une entité est un objet défini non par ses attributs, mais par son identité . A titre d'exemple, la plupart des compagnies aériennes attribuent un numéro unique aux sièges sur chaque vol : c'est l'identité du siège.

En revanche, un objet valeur est un objet immuable qui contient des attributs mais n'a pas d'identité conceptuelle. Lorsque les gens échangent des cartes de visite, par exemple, ils ne se soucient que des informations sur la carte (ses attributs) plutôt que d'essayer de faire la distinction entre chaque carte unique.

Les modèles peuvent également définir des événements (quelque chose qui se produit). Un événement de domaine est un événement auquel les experts du domaine se soucient.

Les modèles peuvent être liés ensemble par une entité racine pour devenir un agrégat . Les objets en dehors de l'agrégat sont autorisés à contenir des références à la racine mais pas à tout autre objet de l'agrégat. La racine d'agrégat vérifie la cohérence des changements dans l'agrégat. Les conducteurs n'ont pas à contrôler individuellement chaque roue d'une voiture, par exemple : ils conduisent simplement la voiture. Dans ce contexte, une voiture est un agrégat de plusieurs autres objets (le moteur, les freins, les phares, etc.)

Travailler avec des modèles

Dans la conception axée sur le domaine, la création d'un objet est souvent séparée de l'objet lui-même.

Un référentiel , par exemple, est un objet avec des méthodes pour récupérer des objets de domaine à partir d'un magasin de données (par exemple une base de données). De même, une fabrique est un objet avec des méthodes pour créer directement des objets de domaine.

Lorsqu'une partie de la fonctionnalité d'un programme n'appartient conceptuellement à aucun objet, elle est généralement exprimée en tant que service .

Relation avec d'autres idées

Bien que la conception axée sur le domaine ne soit pas intrinsèquement liée aux approches orientées objet , dans la pratique, elle exploite les avantages de telles techniques. Ceux-ci incluent des entités/racines agrégées en tant que récepteurs d'appels de commandes/méthodes, l'encapsulation de l'état au sein des racines agrégées les plus importantes et, à un niveau architectural supérieur, des contextes délimités.

Par conséquent, la conception axée sur le domaine est souvent associée à des objets Java simples et à des objets CLR simples . Bien que les détails d'implémentation techniquement techniques, spécifiques à Java et au .NET Framework respectivement, ces termes reflètent une opinion croissante selon laquelle les objets de domaine doivent être définis uniquement par le comportement commercial du domaine, plutôt que par un cadre technologique plus spécifique.

De même, le modèle des objets nus soutient que l'interface utilisateur peut simplement être le reflet d'un modèle de domaine suffisamment bon. Exiger que l'interface utilisateur soit le reflet direct du modèle de domaine forcera la conception d'un meilleur modèle de domaine.

La conception axée sur le domaine a influencé d'autres approches du développement de logiciels.

La modélisation spécifique à un domaine , par exemple, est une conception axée sur le domaine appliquée avec des langages spécifiques à un domaine . La conception axée sur le domaine ne nécessite pas spécifiquement l'utilisation d'un langage spécifique au domaine , bien qu'il puisse être utilisé pour aider à définir un langage spécifique au domaine et prendre en charge la multimodélisation spécifique au domaine .

À son tour, la programmation orientée aspect facilite la prise en compte des problèmes techniques (tels que la sécurité, la gestion des transactions, la journalisation) d'un modèle de domaine, leur permettant de se concentrer uniquement sur la logique métier.

Ingénierie et architecture dirigées par les modèles

Bien que la conception axée sur le domaine soit compatible avec l' ingénierie et l' architecture axées sur les modèles , l'intention derrière les deux concepts est différente. L'architecture pilotée par modèle est plus concernée par la traduction d'un modèle en code pour différentes plates-formes technologiques que par la définition de meilleurs modèles de domaine.

Cependant, les techniques fournies par l'ingénierie dirigée par les modèles (pour modéliser des domaines, créer des langages spécifiques à un domaine pour faciliter la communication entre les experts du domaine et les développeurs,...) facilitent la conception axée sur le domaine dans la pratique et aident les praticiens à tirer le meilleur parti de leur des modèles. Grâce aux techniques de transformation de modèle et de génération de code de l'ingénierie dirigée par les modèles, le modèle de domaine peut être utilisé pour générer le système logiciel réel qui le gérera.

Ségrégation de responsabilité de requête de commande

Command Query Responsibility Segregation (CQRS) est un modèle architectural permettant de séparer les données de lecture (une « requête ») de l'écriture dans les données (une « commande »). CQRS dérive de Command and Query Separation (CQS), inventé par Bertrand Meyer .

Les commandes changent d'état et sont approximativement équivalentes à l'appel de méthode sur des racines ou des entités agrégées. Les requêtes lisent l'état mais ne le modifient pas.

Bien que CQRS ne nécessite pas de conception axée sur le domaine, il rend explicite la distinction entre les commandes et les requêtes avec le concept de racine agrégée. L'idée est qu'une racine agrégée donnée a une méthode qui correspond à une commande et qu'un gestionnaire de commandes appelle la méthode sur la racine agrégée.

La racine agrégée est responsable de l'exécution de la logique de l'opération et de la génération d'un certain nombre d'événements, d'une réponse d'échec ou simplement de la mutation de son propre état qui peut être écrit dans un magasin de données. Le gestionnaire de commandes récupère les problèmes d'infrastructure liés à la sauvegarde de l'état de la racine agrégée et à la création des contextes nécessaires (par exemple, les transactions).

Sourcing événementiel

L'approvisionnement d'événements est un modèle architectural dans lequel les entités ne suivent pas leur état interne au moyen d'une sérialisation directe ou d'un mappage objet-relationnel, mais en lisant et en livrant des événements à un magasin d'événements .

Lorsque la recherche d'événements est associée à CQRS et à une conception pilotée par domaine, les racines agrégées sont chargées de valider et d'appliquer les commandes (souvent en faisant appeler leurs méthodes d'instance à partir d'un gestionnaire de commandes), puis de publier les événements. C'est également le fondement sur lequel les racines agrégées fondent leur logique pour traiter les invocations de méthode. Par conséquent, l'entrée est une commande et la sortie est un ou plusieurs événements qui sont enregistrés dans un magasin d'événements, puis souvent publiés sur un courtier de messages pour les personnes intéressées (comme la vue d' une application ).

La modélisation des racines agrégées en événements de sortie peut isoler encore plus l'état interne que lors de la projection de données de lecture à partir d'entités, comme dans les architectures standard de transmission de données à n niveaux. Un avantage important est que les prouveurs de théorèmes axiomatiques (par exemple, Microsoft Contracts et CHESS) sont plus faciles à appliquer, car la racine agrégée masque complètement son état interne. Les événements sont souvent persistants en fonction de la version de l'instance racine agrégée, ce qui produit un modèle de domaine qui se synchronise dans les systèmes distribués via une simultanéité optimiste .

Outils notables

Bien que la conception axée sur le domaine ne dépende d'aucun outil ou cadre particulier, les exemples notables incluent :

Actifsource , un plug-in pour Eclipse qui permet le développement de logiciels combinant DDD avec l' ingénierie dirigée par les modèles et la génération de code .
CubicWeb , un framework web sémantique open source entièrement piloté par un modèle de données. Les directives de haut niveau permettent d'affiner le modèle de données de manière itérative, version après version. Définir le modèle de données est suffisant pour obtenir une application Web fonctionnelle. Des travaux supplémentaires sont nécessaires pour définir comment les données sont affichées lorsque les vues par défaut ne sont pas suffisantes.
OpenMDX , un framework MDA open source basé sur Java prenant en charge Java SE , Java EE et .NET . OpenMDX diffère des frameworks MDA typiques en ce sens qu'il "utilise des modèles pour piloter directement le comportement d'exécution des systèmes opérationnels" .
Objets Restful , une norme pour mapper une API Restful sur un modèle d'objet de domaine (où les objets de domaine peuvent représenter des entités, des modèles de vue ou des services). Deux frameworks open source (un pour Java, un pour .NET) peuvent créer automatiquement une API Restful Objects à partir d'un modèle de domaine, en utilisant la réflexion.

Voir également

Les références

Liens externes

Conception axée sur le domaine, définitions et résumés de modèles (PDF) , Eric Evans, 2015
Implémentation de la racine agrégée en langage C#
Une introduction à la conception , aux méthodes et aux outils axés sur le domaine

Languages

In other projects