Petit préambule intéressant : Vous vous souvenez de la bonne vieille méthode du cycle en V qui met en face à face dans un V les Spécifications d'une part et le Test et la Validation d'autre part, la conception et les Tests d'intégration etc ... Et bien j'ai lu récemment des articles ayant pour sujet la réhabilitation de ces méthodologies face aux méthodologies agiles.
Comme quoi, il suffit d'attendre assez longtemps et tout fini par arriver.
Alors le DDD c'est quoi ? Encore un truc à la c(bip) pour dégager les vieux codeurs et leur faire croire qu'ils n'ont rien compris ;-)
Patterns in strategic domain-driven design and the relationships between them |
D'après le Xebia blog la conception DDD lie le fonctionnel et le code se serait dommage autrement je ne dis pas que seul le code fait foi car il y a aussi la documentation mais la description fonctionnelle ou la conception et le code source doivent être liés par une relation simple et évidente.
Exemple de DDD : xblanc33/DDDvsJavaBean
Un tour rapide sur la mise en œuvre de la conception DDD c'est brillant d'une très grande clarté.
Je ne peux m'empêcher de citer ici les 3 concepts Utilisé par Xavier Blanc :
Un Value Object est un objet qui représente une valeur et même une constante. L’exemple le plus utilisé est celui du point GPS avec la latitude et la longitude. Chaque point GPS est défini par sa latitude et sa longitude. Du coup, aucun intérêt à changer les valeurs (pas de setter).
Un Service est un objet qui offre une ou plusieurs fonctions (stateless si possible). De fait on peut construire un Service, l’utiliser et le supprimer. Un service n’a pas réellement d’état, c’est juste un ensemble de fonctions.
Un Entity est un objet qui est identifiable et qui a un état propre qui va changer. L’Entity est l’objet « noble » de la programmation orienté objet. Par contre, plutôt que des setter, il offre des méthodes métiers qui vont permettre d’exécuter l’application (on choisira des noms explicites pour ces méthodes).
Une fois ces trois concepts connus, le DDD préconise l’utilisation de Value Object et de Service plutôt que d’Entity. En d’autres mots, il faut essayer de manipuler le plus possible de Value Object et de Service.
Encore une fois ces pages pourraient disparaître, je garde donc une trace minimum pour être capable d'aborder ce sujet de la conception DDD s'il venait à se présenter.
nut&cache - Les méthodes Agiles – La liste complète des méthodologies Agiles
C'est plutôt un ensemble lexicale, on y trouve le FDD : Feature Driven Development (FDD) Le Développement Dirigé par les Fonctionnalités, en français. On parle de modélisation du produit ...
Tout ça est bien joli mais il faut s'accaparer les termes et faire "à sa sauce" en fonction de son expérience (XP).
Qu'avons nous appris ? Pas grand chose que nous ne sachions déjà.
Conception DDD
Pour une fois, on ne parle pas de méthodologie, il s'agit bien d'une façon de concevoir le code.Exemple de DDD : xblanc33/DDDvsJavaBean
Un tour rapide sur la mise en œuvre de la conception DDD c'est brillant d'une très grande clarté.
Je ne peux m'empêcher de citer ici les 3 concepts Utilisé par Xavier Blanc :
Trois concepts à manipuler
Le postulat est le suivant, certes tout est objet, mais tous les objets ne sont pas les mêmes. Il est important de distinguer certains types d'objet : Value Object, Service et Entity.Un Value Object est un objet qui représente une valeur et même une constante. L’exemple le plus utilisé est celui du point GPS avec la latitude et la longitude. Chaque point GPS est défini par sa latitude et sa longitude. Du coup, aucun intérêt à changer les valeurs (pas de setter).
Un Service est un objet qui offre une ou plusieurs fonctions (stateless si possible). De fait on peut construire un Service, l’utiliser et le supprimer. Un service n’a pas réellement d’état, c’est juste un ensemble de fonctions.
Un Entity est un objet qui est identifiable et qui a un état propre qui va changer. L’Entity est l’objet « noble » de la programmation orienté objet. Par contre, plutôt que des setter, il offre des méthodes métiers qui vont permettre d’exécuter l’application (on choisira des noms explicites pour ces méthodes).
Une fois ces trois concepts connus, le DDD préconise l’utilisation de Value Object et de Service plutôt que d’Entity. En d’autres mots, il faut essayer de manipuler le plus possible de Value Object et de Service.
Encore une fois ces pages pourraient disparaître, je garde donc une trace minimum pour être capable d'aborder ce sujet de la conception DDD s'il venait à se présenter.
Méthodes Agiles
Pour vous montrer à quel point, côté Agilité c'est foisonnant, voici une page qui présente toutes les méthodes agiles et leurs concepts :nut&cache - Les méthodes Agiles – La liste complète des méthodologies Agiles
C'est plutôt un ensemble lexicale, on y trouve le FDD : Feature Driven Development (FDD) Le Développement Dirigé par les Fonctionnalités, en français. On parle de modélisation du produit ...
Tout ça est bien joli mais il faut s'accaparer les termes et faire "à sa sauce" en fonction de son expérience (XP).
Qu'avons nous appris ? Pas grand chose que nous ne sachions déjà.
Le DDD et les microservices
Voilà donc deux sujets, fort intéressant du moment, évoqués dans cet article :donetechno - Les microservices : une architecture Agile — Deuxième partie
Pour connaitre les questions principales sur les microservices, un vrai délire architectural. Plein de questions sur les microservices, l'agilité par rapport aux microservices et finalement pas grand chose sur le DDD (Domain Driven Development).
Pour connaitre les questions principales sur les microservices, un vrai délire architectural. Plein de questions sur les microservices, l'agilité par rapport aux microservices et finalement pas grand chose sur le DDD (Domain Driven Development).
Un exemple de code sources en C#
Oui, il y en a qui sont allé jusqu'à l'implémentation en C# voici un article en anglais simple et efficace. Voici donc du code en C# réalisé avec une méthode de conception DDD (Domain Driven Development) :
C’était un exemple de code mais il a disparu du net ! Le projet s'appelais QuoteEngine : DoboTEK - Domain-driven design DDD practical implementation in C# .NET
Visual Studio 2017 - Implémentation du DDD en C# |
Peut être que l'on peut retrouver ce projet sur Gihub à voir j'ai trouvé ça :
Il faudrait retrouver le DDD (Domaine Driven Development) dans ce projet.
Voilà, le DDD ... disons que c'est une méthode de conception centrée sur le domaine métier qui conçoit un modèle commun qui permet aux développeurs d'avoir une meilleure connaissance du fonctionnel et du vocabulaire utilisé par le métier.
Le DDD permet aux gens du métier de mieux visualiser ce que les devs ont en tête pour la conception du logiciel. Le DDD (Domain Drivne Design) permet de meilleurs échanges entre les gens du métier et les devs.
Have fun!