Domain Driven Design

Les patterns

Les designs pattern

Depuis les débuts de la programmation, tout un tas de développeurs ont rencontré différents problèmes de conception. La plupart de ces problèmes étaient récurrents. Pour éviter aux autres développeurs de buter sur le même souci, certains groupes de développeurs ont développé ce qu'on appelle des design patterns (ou masques de conceptions en français). Chaque design pattern répond à un problème précis. Comme nous le verrons dans ce chapitre, certains problèmes reviennent de façon récurrente et nous allons utiliser les moyens de conception déjà inventés pour les résoudre.

Dans le cadre du Domain Driven Design, il existe 3 patterns qui sont priorisés, à savoir:

Les agrégats

Les objets du domaine passent par une série d’états au cours de leur vie. Ils sont créés, placés en mémoire et utilisés dans des traitements, puis ils sont détruits. Dans certains cas ils sont sauvegardés dans des emplacements permanents, comme une base de données, où on peut les récupérer un peu plus tard, ou bien ils sont archivés. A un moment donné ils peuvent être complètement effacés du système, y compris de la base et de l’archive.

Agrégat est un pattern de domaine utilisé pour définir l’appartenance et les frontières des objets.

Un Agrégat est un groupe d’objets associés qui sont considérés comme un tout unique vis-à-vis des modifications de données. L’Agrégat est démarqué par une frontière qui sépare les objets situés à l’intérieur de ceux situés à l’extérieur. Chaque Agrégat a une racine. La racine est une Entité, et c’est le seul objet accessible de l’extérieur.

Les fabriques

Les Entités et les Agrégats peuvent parfois être vastes et complexes – trop complexes pour être créés dans le constructeur de l’entité racine. En fait, essayer de construire un agrégat complexe dans son constructeur serait entrer en contradiction avec la manière dont ça se passe souvent dans le domaine lui-même, où des choses sont créées par d’autres choses.

La création d’un objet a beau être une opération importante en soi, les opérations d’assemblage complexes ne sont pas de la responsabilité des objets créateurs. 46 Combiner de telles responsabilités peut produire des designs disgracieux qui sont difficiles à comprendre.

C’est pourquoi il est nécessaire d’introduire un nouveau concept qui aide à encapsuler le processus de création d’un objet complexe. C’est ce qu’on appelle une Fabrique. Les Fabriques sont utilisées pour encapsuler la connaissance nécessaire à la création des objets, et elles sont particulièrement utiles pour créer des Agrégats. Quand la racine d’un Agrégat est créée, tous les objets contenus dans l’Agrégat sont créés en même temps qu’elle, et tous les invariants sont appliqués.

Les entrepots

Dans une conception dirigée par le modèle, les objets ont un cycle de vie qui commence par leur création et se termine avec leur suppression ou leur archivage. Un constructeur ou une Fabrique se charge de la création de l’objet. Tout l’objectif de créer des objets est de pouvoir les utiliser.

Vous pouvez utiliser un Entrepôt, dont le but est d’encapsuler toute la logique nécessaire à l’obtention de références d’objets. Les objets du domaine n’auront pas à s’occuper de l’infrastructure de récupération des références aux autres objets du domaine dont ils ont besoin. Ils iront simplement les chercher dans l’Entrepôt et le modèle retrouvera sa clarté et sa focalisation.

L’Entrepôt est capable de conserver des références vers des objets. Quand un objet est créé, il peut être sauvegardé dans l’Entrepôt, et y être récupéré plus tard quand on voudra l’utiliser. Si le client demande un objet à l’Entrepôt, et que l’Entrepôt ne l’a pas, ce dernier peut aller le chercher dans l’emplacement de stockage physique. Dans tous les cas, l’Entrepôt agit comme un endroit où sont emmagasinés des objets globalement accessibles.