Domain Driven Design
La conception orientée domaine
Les entités
Il y a une catégorie d’objets dont l’identité semble rester la même au fil des états du logiciel. Chez ces objets, ce ne sont pas les attributs qui comptent, mais une ligne de continuité et d’identité qui s’étend sur la durée de vie d’un système et peut s’allonger au-delà. Ces objets sont appelés Entités.
Lorsqu’un objet se distingue par son identité plutôt que par ses attributs, faites de cela un élément primordial de sa définition dans le modèle. Gardez une définition de la classe simple et focalisée sur la continuité du cycle de vie et l’identité. Définissez une façon de distinguer chaque objet quelle que soit sa forme ou son historique. Restez vigilant par rapport aux spécifications qui demandent à retrouver des objets par leurs attributs. Définissez une opération qui garantit la production d’un résultat unique pour chaque objet, si possible en y rattachant un symbole qui est garanti unique.
Considérons l’exemple d’un système de comptes bancaires. Chaque compte a son propre numéro. Un compte peut être précisément identifié par son numéro. Ce numéro reste inchangé tout au long de la vie du système, et assure la continuité. Le numéro de compte peut exister en tant qu’objet en mémoire, ou il peut être détruit de la mémoire 34 et envoyé à la base de données. Il peut aussi être archivé quand le compte est fermé, mais il existe toujours quelque part.
Les objets-valeurs
Il y a des cas où on a purement besoin de stocker des attributs d’un élément du domaine. Ce qui nous intéresse n’est pas de savoir de quel objet il s’agit, mais quels attributs il a. Un objet qui est utilisé pour décrire certains aspects d’un domaine et qui n’a pas d’identité, est appelé Objet-Valeur.
Il est nécessaire de distinguer les Objets Entités des Objets-Valeurs. Ca ne sert à rien de faire de tous les objets des entités juste pour des raisons d’uniformité. En fait, il est plutôt recommandé de choisir comme entités seulement les objets qui sont conformes à la définition d’une entité. Et de faire du reste des objets des Objets-Valeurs.
Il est fortement recommandé que les objets-valeurs soient immuables. Ils sont créés à l’aide d’un constructeur, et jamais modifiés au cours de leur vie. Lorsque vous voulez une valeur différente pour l’objet, vous en créez tout simplement un autre. Ceci a des conséquences importantes sur la conception. Etant immuables, et n’ayant pas d’identité, les Objets-Valeurs peuvent être partagés. Ca peut s’avérer obligatoire dans certains designs. Les objets immuables sont partageables, avec d’importantes retombées en termes de performances. Ils ont aussi un caractère d’intégrité, au sens intégrité des données.
Imaginez ce que cela voudrait dire de partager un objet qui n’est pas immuable. Un système de réservation de voyages en avion pourrait créer des objets pour chaque vol. Un des attributs pourrait être le code du vol. Un client réserve un vol pour une destination donnée. Un autre client veut réserver sur le même vol. Le système choisit de réutiliser l’objet qui comporte le code du vol, parce qu’il s’agit du même vol. Entretemps, le client change d’avis, et choisit de prendre un vol différent. Le système change le code du vol car il n’est pas immuable. Résultat, le code du vol du premier client change aussi.
Les services
Lorsqu’on élabore le Langage omniprésent, les concepts clés du domaine sont introduits dans le langage, et les noms de ce dernier sont facilement convertibles en objets. Les verbes du langage, associés aux noms correspondants, viennent former une partie du comportement de ces objets. Mais il y a certaines actions dans le domaine, certains verbes, qui ne semblent appartenir à aucun objet.
Un tel objet n’a pas d’état interne, et son objectif est simplement de fournir de la fonctionnalité au domaine.
Le plus souvent on va retrouver ce genre de service en accédant à une méthode statique d'une classe.
Les modules
Lorsque le domaine tend à devenir de plus en plus grand, il devient alors plus difficile de décrire les intéractions entres les différents objets et services qui peuvent être proposé.
Les modules sont largement utilisés dans la plupart des projets. Il est plus facile de saisir le tableau d’ensemble d’un gros modèle si vous regardez les modules qu’il contient, puis les relations entre ces modules. Une fois qu’on a compris l’interaction entre les modules, on peut commencer à s’intéresser aux détails à l’intérieur d’un module. C’est une manière simple et efficace de gérer la complexité.