Qu'est-ce que la conception pilotée par domaine (DDD)? [fermé]

Je continue de voir que DDD (Domain Driven Design) est beaucoup utilisé dans les articles - J'ai lu l'entrée Wikipedia sur DDD mais je n'arrive toujours pas à comprendre ce que c'est réellement et comment je pourrais l'implémenter dans la création de mes sites?

Premièrement, si vous ne savez pas que vous en avez besoin, il est possible que vous n'en ayez pas besoin. Si vous ne reconnaissez pas les problèmes que DDD résout, alors vous n'avez peut-être pas ces problèmes. Même les défenseurs de DDD feront souvent remarquer que DDD est uniquement destiné aux grands projets (> 6 mois).

En supposant que vous lisez encore à ce stade, mon opinion sur DDD est la suivante:

DDD consiste à essayer de faire de votre logiciel un modèle de système ou de processus réel. En utilisant DDD, vous êtes censé travailler en étroite collaboration avec un expert du domaine qui peut expliquer le fonctionnement du système réel. Par exemple, si vous développez un système qui gère le placement des paris sur les courses de chevaux, votre expert en domaine peut être un bookmaker expérimenté.

Entre vous et l'expert du domaine, vous construisez un langage omniprésent (UL), qui est essentiellement une description conceptuelle du système. L'idée est que vous devriez pouvoir noter ce que fait le système de manière à ce que l'expert du domaine puisse le lire et vérifier qu'il est correct. Dans notre exemple de paris, le langage omniprésent inclurait la définition de mots tels que «race», «pari», «cotes» et ainsi de suite.

Les concepts décrits par l'UL formeront la base de votre conception orientée objet. DDD fournit des conseils clairs sur la façon dont vos objets doivent interagir et vous aide à diviser vos objets dans les catégories suivantes:

• Objets de valeur, qui représentent une valeur pouvant avoir des sous-parties (par exemple, une date peut avoir un jour, un mois et une année)
• Entités, qui sont des objets d' identité . Par exemple, chaque objet Client a sa propre identité, nous savons donc que deux clients portant le même nom ne sont pas le même client
• Les racines agrégées sont des objets qui possèdent d'autres objets. C'est un concept complexe et fonctionne sur la base qu'il y a des objets qui n'ont de sens que s'ils ont un propriétaire. Par exemple, un objet 'Order Line' n'a pas de sens sans un 'Order' auquel appartenir, donc nous disons que l'Ordre est la racine agrégée, et les objets Order Line ne peuvent être manipulés que via des méthodes dans l'objet Order

DDD recommande également plusieurs modèles:

• Référentiel , modèle de persistance (enregistrement et chargement de vos données, généralement vers / depuis une base de données)
• Factory , un modèle pour la création d'objets
• Service, un modèle pour créer des objets qui manipulent les objets de votre domaine principal sans faire partie du domaine eux-mêmes

Maintenant, à ce stade, je dois dire que si vous n'avez jamais entendu parler de ces choses auparavant, vous ne devriez pas essayer d'utiliser DDD sur un projet pour lequel vous avez une échéance. Avant d'essayer DDD, vous devez vous familiariser avec les modèles de conception et les modèles de conception d'entreprise . Le fait de les connaître rend DDD beaucoup plus facile à saisir. Et, comme mentionné ci-dessus, il existe une introduction gratuite à DDD disponible auprès d'InfoQ (où vous pouvez également trouver des discussions sur DDD).

Prenons StackOverflow comme exemple. Au lieu de commencer à concevoir certains formulaires Web, vous vous concentrez d'abord sur la modélisation orientée objet des entités au sein de votre domaine problématique, par exemple les utilisateurs, les questions, les réponses, les votes, les commentaires, etc. La conception étant guidée par les détails du problème domaine, il est appelé conception pilotée par domaine .

Vous pouvez en lire plus dans le livre d'Eric Evans .