LG

Cette page est en lecture seule. Vous pouvez afficher le texte source, mais ne pourrez pas le modifier. Contactez votre administrateur si vous pensez qu'il s'agit d'une erreur.
[[https://www.infoq.com/fr/minibooks/domain-driven-design-quickly/|Domain-Driven Design Vite fait]] {{ :doc:architecture:ddd:dddvitefait.pdf |Archive du 27/05/2013 le 10/08/2020}}

[[https://www.amazon.fr/Domain-Driven-Design-Tackling-Complexity-Software/dp/0321125215|Domain-Driven Design - Tackling Complexity in the Heart of Software]] [[prive:doc:architecture:ddd|En savoir plus]]

====Introduction====

Cette méthode s'applique aussi bien aux projets en cycle en V (projet complet) ou aux méthodes agiles (point particulier d'un projet). Elle a pour but de les améliorer afin de réduire leurs défaut.

Cycle en V : l'architecte conçoit et le développeur code. On n'a pas de passage d'information (feedback) dans les deux sens, notamment développeur vers architecture.

Méthode agile : on ne conçoit pas tout depuis le début. On développe les fonctionnalités selon un processus itératif. Cela crée un risque important de refactoring.

====Méthodologie====

===Domaine===

Il faut commencer par connaître le domaine en se renseignant avec ces utilisateurs. Le domaine est la compétence des utilisateurs.

===Modèle===

Puis on crée une abstraction/modèle du domaine (représentation interne du domaine) en demandant aux utilisateurs de décrire leurs besoins. Un domaine peut être décomposé en de nombreux modèles.

La description d'un modèle pourrait se faire par des diagrammes UML / BPMN.

Il faut partager la connaissance pour établir un domaine. Définir un vocabulaire commun entre les différents types d'utilisateur (et pas celui du développeur).

Le code source du modèle du domaine doit être compréhensible par les utilisateurs (langage omniprésent).

Pour créer le modèle, au départ, il faut lire les spécifications fonctionnelles et de chercher les noms et les verbes. Les noms sont convertis en classes, tandis que les verbes deviennent des méthodes.

Établir un langage commun entre les utilisateurs. Ne pas aller trop loin dans le détail (se limiter à définir ce que l'utilisateur comprend).

On défini le problème, pas la solution technique.

Noter les évènements (interaction utilisateur ou logiciels). On peut partir de l'objectif final de l'application puis remonter le plus en amont possible.

Définir les usecase pour chaque utilisateur.

====Terminologie====

Cette terminologie défini également les bonnes pratiques de codage.

  * Architecture en couche

C'est le modèle MVC avec la base de données.

  * Entité

C'est une classe qui est identifiable par une clé (pour la persistance). Il ne doit pas être possible d'avoir deux classes différentes avec la même clé. Les attributs composants la clé ne doit jamais évoluer durant la durée de vie de l'entité. La clé est l'identité de l'objet. Les autres attributs sont modifiables.

  * Objet-valeur

Ce sont des objets n'ayant pas de clé et dont les attributs sont immuables (une adresse par exemple). Si on veut modifier une valeur, on crée un double en changeant l'attribut. Les objets valeurs peuvent être partagés. L'immuabilité est importante.

  * Services

Les objets / entités ont des attributs, un état interne qu'ils gèrent et ils exposent un comportement.

Les services sont des actions (stateless) qui ne s'intègrent pas naturellement à un objet / entité mais utilisent des objets du domaine. Cela réduit le degré de couplage.

Il faut différentier les services du domaine, de l'infrastructure et de l'application (comment ?).

  * Module

Découper le modèle en module pour le rendre plus lisible et réduire le degré de couplage. Courant en informatique.

  * Agrégat

Pour réduire le nombre d'entité / objet-valeur, on peut utiliser des agrégats. C'est une entité racine qui est l'unique passerelle vers ses entités / objets-valeurs enfants.

Elle seule peut lire et modifier ses enfants. Par contre, ses enfants peut avoir accès au monde extérieur si besoin.

  * Fabrique

C'est la fabrique abstraite. On crée une méthode qui renvoie une entité ou un objet-valeur.

Si c'est une fabrique d'entité, la méthode peut avoir peu de paramètres et initialiser un comportement par défaut.

Si c'est une fabrique d'objet-valeur, la méthode doit avoir tous les paramètres, les objets-valeur étant immuables.

On utilise directement un constructeur si le constructeur est simple, si le constructeur ne crée pas d'autres objets, 

  * Entrepôt

Stocker les objets dans un entrepôt. C'est la fabrique qui crée les nouveaux. C'est l'équivalent d'un ORM mais avec une interface pour ne pas s'occuper de l'implémentation.

  * Stratégie

C'est une manière de dire qu'on met l'algorithme à part dans un service externe.

  * Règle

C'est des pré-conditions qui doivent être séparé des objets séparés si possible. Ces objets sont des spécifications du client :

<code cpp>
Client client = entrepotClients.trouverClient(identiteClient);
…
Specification clientEligiblePourRemboursement = new
  Specification(
    new clientAPayeSesDettesDansLePasse(),
    new clientNAPasDeSoldesNegatifs());
if(clientEligiblePourRemboursement.estSatisfaitePar(client)
{
  serviceRemboursement.envoyerRemboursementA(client);
}
</code>

====Commentaires====

Le design pattern n'est pas l'architecture / conception du logiciel. C'est des bonnes pratiques de code pour créer une code propre et maintenable.