[JAVA] Qu'est-ce que la conception axée sur le domaine tente de résoudre [DDD]

Que dit Eric Evans sur la définition de la conception axée sur le domaine Dans l'article, j'ai cité la définition d'Eric Evans du pilotage de domaine et je l'ai traduite en japonais comme suit.

Concentrez-vous sur la complexité fondamentale et les opportunités du domaine
Explorez les modèles en collaboration avec des experts du domaine et des logiciels
Écrire un logiciel qui représente explicitement ces modèles
Parlez dans une langue omniprésente dans un contexte limité

En cela, les points importants n'ont pas été précisés.

*** Pourquoi devons-nous faire quelque chose comme les quatre dans la définition? *** à propos de ça.

Alors, qu'est-ce que la conception axée sur le domaine *** essaie de résoudre exactement? *** ***

Qu'est-ce que la conception axée sur le domaine tente de résoudre?

DDD est l'une des méthodes de développement logiciel. Alors tout d'abord, réfléchissons à l'objectif du développement logiciel.

Pourquoi les gens développent-ils des logiciels? On peut dire que *** est de résoudre un problème de la cible de la softwareisation.

Cette "cible à convertir en logiciel" est appelée "domaine". Le logiciel provient d'un domaine particulier et est profondément impliqué dans ce domaine.

Alors, quelle est l'approche de DDD en matière de développement logiciel? [Référence DDD](http: /) également mentionné dans Que dit Eric Evans de la définition de la conception pilotée par domaine Au début de /domainlanguage.com/ddd/reference/), il y a une description comme celle-ci.

Many projects do modeling work without getting much real benefit in the end. The patterns of DDD distill successful practices from projects where dramatic benefits have come from modeling.
De nombreux projets se soldent par des gains significatifs de *** modélisation. *** DDD extrait des modèles réussis de projets qui ont grandement bénéficié *** de la modélisation ***.

Autrement dit, DDD est

*** Augmentez la valeur de votre logiciel grâce à la modélisation de domaine ***

Nous adoptons l'approche.

Alors, que signifie bénéficier de la modélisation?

Que signifie «bénéficier de la modélisation»?

Commençons par vérifier la définition du modèle. Selon la définition d'Eric Evans, *** "une abstraction d'un aspect particulier des choses pour résoudre un problème" ***. Le monde réel ne peut pas être transformé en logiciel tel quel. Il doit être abstrait d'une manière adaptée à la résolution de problèmes, et le produit est un modèle.

Prenons un exemple concret.

Exemple: modélisation de rapports quotidiens

Par exemple, j'ai une entreprise pour rédiger un rapport quotidien sur papier. "Je n'ai pas d'endroit pour mettre physiquement le rapport quotidien, donc je veux le compléter en ligne." Supposons qu'il soit systématisé pour résoudre le problème.

Il y a beaucoup d'informations dans le monde réel.

Le nom de la personne qui a rédigé le rapport quotidien, la date et le contenu du rapport quotidien,
Nombre de pages, prix, matériel, acheteur, de livret pour rédiger un rapport quotidien
Lieu pour fermer le rapport quotidien, stylo pour rédiger le rapport quotidien, lieu, heure ...

Il y a une infinité d'informations selon la façon de découper.

Comme mentionné ci-dessus, il est impossible et pas nécessaire de mettre tout cela dans un logiciel.

Par conséquent, dans ce logiciel, nous avons défini comme suit les informations nécessaires pour résoudre le problème ci-dessus.

Le nom de la personne qui a rédigé le rapport quotidien, la date et le contenu du rapport quotidien

Voici le modèle.

Qu'est-ce qu'un bon modèle

Alors, qu'est-ce qu'un bon modèle? Considérant la définition de "une abstraction d'un aspect spécifique des choses pour résoudre un problème", un bon modèle peut résoudre le *** problème et un mauvais modèle qui ne le peut pas.

Alors, quel est le modèle qui ne peut pas résoudre le problème? Prenons l'exemple d'un rapport quotidien.

Lors de l'analyse du rapport d'activité quotidien (ci-après, domaine), En fait, le rapport quotidien est utilisé pour échanger les commentaires de mon supérieur, et j'ai trouvé que cela ne peut pas être éliminé sans cette systématisation.

Cependant, le modèle de rapport quotidien actuel ne contient que les informations «la personne qui rédige le rapport quotidien, la date et le contenu du rapport quotidien». Cela ne peut pas exprimer le concept de feedback et ne peut pas résoudre le problème «Je veux compléter le rapport quotidien en ligne» qui existe dans le domaine.

En d'autres termes, le modèle précédent est inadéquat et un mauvais modèle.

Alors, comment faire un bon modèle et bénéficier de la modélisation?

Approche pour profiter de la modélisation

Comme vous pouvez le voir dans le cas du rapport quotidien, pour résoudre le problème, il est nécessaire de comprendre correctement le domaine et de le refléter dans le modèle. De plus, pour ajouter de la valeur en tant que logiciel, il est nécessaire de la refléter du modèle au logiciel.

Par conséquent, DDD se divise grossièrement en deux approches illustrées dans la figure ci-dessous.

1. Approfondissez votre compréhension des domaines et continuez à améliorer votre modèle

Dans l'exemple ci-dessus, nous avons constaté que sans une compréhension du domaine, le problème ne pouvait pas être résolu correctement. Alors, comment comprenez-vous le domaine?

Oui, vous devez demander à quelqu'un qui connaît *** les domaines ***.

À quelle fréquence écoutez-vous?

Dois-je le modéliser, publier le logiciel et ensuite obtenir des commentaires? Il n'est pas difficile d'imaginer qu'il vaut mieux faire correspondre les perceptions au stade de la création du modèle ***. Une fois que vous avez créé et mis à jour votre modèle, il est préférable de réconcilier vos perceptions à chaque fois, et vous aurez moins de retouches et plus de chances d'amélioration précoce de votre modèle.

En d'autres termes, pour approfondir votre compréhension du domaine *** Il est important d'obtenir le plus souvent possible des commentaires sur le modèle de la part de personnes familières avec le domaine ***

Approche définie

DDD nomme et définit cette approche.

Les personnes qui connaissent les domaines sont appelées *** «experts du domaine» *** et, en principe, nous utilisons les mêmes mots que les experts du domaine et «explorons» les modèles ensemble.

À l'heure actuelle, afin d'éviter les écarts de reconnaissance et de réduire le coût de conversion de différents mots, il est également un principe que tous les experts et développeurs du domaine "utilisent les mêmes mots", et ce mot est *** "langage omniprésent". Nous l'appelons ***.

Aussi, comme il n'est pas réaliste de dire «un modèle commun au monde entier» et «un modèle commun à toute l'entreprise», c'est une frontière pour le clarifier à partir de l'idée de décider du champ d'application de ce modèle. Le contexte joint est "***".

Veuillez consulter cet article pour une explication détaillée de ce domaine. Concept de contexte délimité Implémentation de contexte délimité

2. Refléter en permanence le modèle dans le logiciel

Au fur et à mesure que le modèle s'améliore, il devient naturellement nécessaire de conserver les changements reflétés dans le logiciel. Être capable de gérer cela est une exigence majeure pour un logiciel ***!

Étant donné que le modèle normal est proche de la base de données, il est facile d'éviter les changements autant que possible compte tenu du coût. Sans une solide préparation au niveau architectural, il sera difficile de répondre à cette demande.

D'autre part, dans DDD

Ecrire un logiciel qui exprime le modèle tel qu'il est
Utilisez des modèles de conception DDD éprouvés

Nous préconisons l'approche.

Ecrire un logiciel qui représente un modèle

Pour que la cartographie modèle-logiciel soit claire *** Nous visons à exprimer le plus possible le modèle sur logiciel ***. Veuillez vous référer à l'article Qu'est-ce qu'exprimer la connaissance du domaine avec un modèle pour un exemple concret. S'il te plait donne moi.

Ceci pour des raisons pratiques.

Plus le modèle est complexe, plus il est difficile de comprendre son mappage et plus il est difficile de refléter les changements fréquents lorsqu'il y a un écart entre le code et le modèle. De plus, même si vous essayez de décrire les informations du modèle dans un document, le document est souvent obsolète et il est fort possible que la connaissance du modèle ne soit pas reflétée ou qu'il soit transmis dans un état incorrect.

«Omniprésent» dans le concept de langage omniprésent mentionné ci-dessus signifie «partout», ce qui signifie «***» dans les déclarations des experts du domaine, des développeurs et *** »des logiciels. ..

Utilisez des modèles de conception DDD éprouvés

C'est exactement ce que l'on appelle le "DDD tactique". Pour résister aux modifications fréquentes du code, il nécessite un niveau de maintenabilité assez élevé. À cette fin, les entités et les référentiels sont définis comme des *** modèles de conception hautement cohésifs *** dérivés de divers projets.

Généralement reconnu (et probable) comme un avantage du DDD, *** "Ecrire du code facile à maintenir" n'était pas vraiment l'objectif principal ***. La position correcte est que les modèles tels que les entités célèbres étaient des sous-produits créés pour atteindre leurs objectifs.

En passant, le modèle qui n'introduit que le DDD tactique est parfois appelé «DDD léger». Personnellement, je pense que cela a du sens si vous pensez que "seule une bonne conception qui peut résister à de fréquents changements de modèle" est prise en considération. Cependant, il y a un modèle à la base de l'idée, donc si vous y réfléchissez sans lui, je pense qu'il y aura quelques rides.

Résumé

Pourquoi faites-vous DDD en premier lieu? Je pense qu'il n'y avait pas beaucoup d'occasions d'explorer cela. En comprenant cela en premier, je pense que vous serez en mesure de travailler avec des intentions plutôt que de simplement tracer l'approche définie dans DDD.

Si vous voulez en savoir plus

Nous avons publié un livre pour ceux qui apprennent le DDD pour la première fois, ou pour ceux qui ont réellement commencé et rencontrent des difficultés.

Guide de modélisation / mise en œuvre de la conception pilotée par domaine

En commençant par une explication du «but de DDD» et du «modèle» qui ont tendance à se perdre Nous visons à expérimenter l'attrait et les effets du DDD sur la base d'exemples de modélisation et de mise en œuvre concrètes.

Le «Chapitre 1 Présentation de DDD» de ce livre fournit une explication plus détaillée du contenu de cet article. Veuillez acheter si vous le souhaitez.

Sur Twitter, nous envoyons également des questions sur DDD et acceptons les questions via un service appelé "Boîte à questions". Veuillez me suivre si vous le souhaitez.

@little_hand_s