Domain-Drive Design Flashcards
Quelles sont les deux composantes fondamentales pour avoir une modélisation viable ?
Il faut que sa construction soit itérative, et que les développeurs aient une très bonne communication avec les experts du domaine.
Qu’est ce que l’analyse paralysante ?
C’est quand on a trop de documents inutiles, trop de specs en avance, et que cela nous bloque pour avancer.
Qu’est ce qu’un modèle ?
Une connaissance sélectionnée, simplifiée et structurée d’un élément d’un domaine.
Qu’est ce qu’une modélisation ?
Le fait de lier plusieurs modèles entre eux afin de créer un ensemble représentant le domaine.
Par qui le modèle doit être compris ?
Par tous les gens de l’entreprise. Ce doit être un langage commun.
Comment les modèles doivent ils être conçus ?
Par le knowledge crunching (du brainstorming avec les experts du domaine et les développeurs), et de l’itération (des expérimentations)
Qu’est ce qu’un langage ubiquitaire ?
C’est quand on utilise le même vocabulaire entre experts et développeurs.
Que permet d’éviter le langage ubiquitaire ?
Les traductions entre les services, ce qui amène à une incompréhension du modèle.
Qu’induit un changement du langage ubiquitaire ?
Un refactoring dans le code.
Qu’est ce qui ne fait pas parti du langage ubiquitaire ?
Les termes techniques (patterns, code…), les termes business qui sont inconnus au développeur.
Que faut il éviter avec les diagrammes UML ?
Qu’ils contiennent trop d’informations. Il faut éviter les implémentations techniques dedans (signatures des fonctions par ex, type des variables..)
Peut on représenter tout le domaine via UML ?
C’est impossible : trop gros, complétement indigeste pour tout le monde. Il faut faire une belle doc qui va séparer en petits diagrammes.
Que doit faire la documentation ?
Compléter le code et la parole. Avoir une vision en hauteur, sans trop rentrer dans les détails. Apprendre pas à pas la modélisation.
Que doit on faire au niveau du code avec le langage ubiquitaire ?
Utiliser le même vocabulaire partout, même pour nos classes.
Qui doit faire la conception des logiciels ?
Les développeurs qui vont réaliser le logiciel. Ce sont les lead développeurs qui vont lier la modélisation du domaine avec la conception du logiciel.
En combien de couches l’auteur de DDD propose de séparer une application ?
4 : UI, Applicative, Domain, Infrastructure
Que faut il faire avec les relations de models ?
Il faut les réduire au maximum, pour avoir le moins de chemins possibles.
Que faut il faire avec les relations bidirectionnelle ?
Le rendre unidirectionnelle, pour simplifier la modélisation. On va garder la relation directionnelle la plus forte, qui a le plus de sens (Formuler la question pour trouver)
Qu’est ce qu’une entité ?
Un model qui a une continuité, une vie dans le SI
Que doit on s’assurer avec les entités ?
Qu’ils aient un identifiant unique à travers tout le SI, et qu’on ne se base pas sur des attributs mouvants (coucou l’email)
Qu’est-ce qu’un Service ?
Une classe qui va coordonner une action en prenant en paramètre des models. Son nom doit être un verbe, tiré du langage uniquitaire.
Qu’est ce qu’un Value Object en DDD ?
Un model mais qui n’est pas une intentité
Qu’est-ce qu’un Aggregate en DDD?
Un ensemble composé d’une Entité racine et de plusieurs Objects Values qui la référence.
Que doit on s’assurer avec les Aggregate en DDD ?
Si l’entité est mise à jour (ajout ou suppression id), les Objects Values doit être immédiatement mises à jour. Les références externes à l’Entité de l’Aggregation peuvent être faite en asynchrone.
Qu’est ce qu’un Repository ?
Une classe qui va faire créer nos objets de la DB vers l’application. Il va pouvoir aussi faire des recherches plus complexes, avec des filtres…
Qu’est ce qu’une Specification en DDD ?
Un object Value mais dédié à produite un résultat Booléen (ex : isValid). Permet de séparer cette logique de du model, mais quand même mettre en avant dans la modélisation
Peut avoir un model identique (exemple un utilisateur) pour tous le SI ?
Non, car il ne matcherai pas pour tous les besoins des Apps.
Qu’est ce qu’un Bounded Context ?
C’est le périmètre dans lequel un modèle peut agir
