[JAVA] Réponse aux questions sur DDD [Domain Driven Design]

L'autre jour, j'ai visité Mediamax Japan (ci-après dénommé MMJ) et organisé une session d'étude de conception axée sur le domaine. Il y avait une session de questions et réponses là-bas, et nous avons répondu à diverses questions spécifiques qui se sont posées lorsque nous avons commencé à développer avec une conception axée sur le domaine. Peut-être que beaucoup de gens auraient des questions similaires, alors je voudrais les présenter ici avec la permission de MMJ.

Comment diviser le contexte

Est-il acceptable d'utiliser DB en commun pour plusieurs contextes?
Est-il acceptable de ne pas avoir de schéma?

Nous vous recommandons de conserver le schéma au minimum pour chaque contexte. Veuillez vous référer à l'article suivant pour plus de détails.

Glossaire de conception axée sur le domaine de l'implémentation de contexte délimité

Couper pour chaque fonction? Le contexte doit-il être séparé pour chaque type d'utilisateur?
Comment puis-je déterminer si le contexte est correctement coupé?

La conception de contexte n'a pas d'organigramme qui peut être créé en fonction de cela. En réalité, nous devons penser à la fois d'un point de vue conceptuel et d'une perspective de mise en œuvre. En tant qu'approche heuristique, je pense qu'il serait préférable de vérifier à partir de plusieurs perspectives comme suit.

• Est-ce approprié comme domaine qui sépare la signification du modèle? Un modèle a-t-il plusieurs significations?
• Astuce pour les frontières culturelles et organisationnelles
• Est-il approprié de diviser le domaine (domaine du problème) plutôt que le contexte (domaine de résolution)?
• Existe-t-il une image d'implémentation comme moyen de couper l'application?
• Pensez-y comme un moyen de couper les micro-services
• La taille de l'équipe est-elle appropriée?
• En règle générale, 6 à 8 personnes sont considérées comme le maximum)
• Pouvez-vous bien le nommer?
• Si vous ne pouvez pas le nommer, vous avez peut-être une mauvaise idée.

Puis-je partager le même modèle avec un autre contexte?

"Même modèle" n'est pas partagé.
En effet, la définition d'un contexte borné est "une portée explicite à laquelle un modèle s'applique". Le partage dans plusieurs contextes viole cette définition.

Cependant, cela ne signifie pas que "les objets portant le même nom ne peuvent pas exister dans plusieurs contextes".

"Définissez des modèles avec le même nom mais un comportement différent dans chaque contexte."

Ensuite, il est nécessaire de clarifier la relation entre les modèles à travers le contexte. Il s'agit de la cartographie du contexte.

Validation

Comment écrire la validation?

Il existe plusieurs types d'histoires de validation. Cette zone est le matériel sur lequel je veux écrire.

• Restrictions de domaine → Valider au niveau de la couche de domaine, lever des exceptions et laisser le traitement à l'application
• Contraintes applicatives → Ecrire au besoin

À propos de la conception pilotée par domaine

Cette écriture est-elle bonne? J'écris en m'inquiétant. Existe-t-il une meilleure pratique?

Il n'y en a pas! Lol (peut-être) La conception axée sur le domaine est inévitablement impliquée dans l'histoire architecturale, ce qui nécessite beaucoup de prise de décision. À ce stade, plusieurs options peuvent être prises en termes de conception axée sur le domaine, et il est nécessaire de toujours prendre en compte les avantages, les inconvénients et les coûts et de décider dans quelle mesure incorporer le concept de conception axée sur le domaine.
Par conséquent, je me demande s'il est difficile de faire quelque chose qui dit "c'est la bonne réponse". ..

Si vous voulez dire «exemple de code» au lieu de «meilleure pratique», le livre Practice DDD contient un exemple de code pour le livre. Il peut être bon de commencer avec ce livre + un exemple.

Si vous effectuez correctement toute la conception axée sur le domaine, vous tomberez dans une conception excessive. Combien de temps dois-je le conserver?

Comme mentionné ci-dessus, la conception d'une conception axée sur le domaine est une pile de bonnes décisions.

Idéalement, il est préférable de comprendre les avantages, les inconvénients et les coûts de chaque fois et de prendre une décision équilibrée. Cependant, il y a beaucoup de choses que nous ne comprenons pas depuis le début, il est donc nécessaire de procéder dans une certaine mesure. De plus, nous pouvons intentionnellement compromettre la conception en tenant compte des performances de coût.

Je pense qu'il est important de pouvoir répondre à la raison plus tard, pas «d'une manière ou d'une autre» lors de la prise d'une décision appropriée.

À propos du CQRS

Les données obtenues par requête CQRS ne sont plus un modèle de domaine?

Quel type d'objet les données acquises doivent-elles être traitées? Oui, vous pouvez penser que ce que vous obtenez avec le modèle de requête n'est pas le modèle de domaine. Nommons le modèle de la requête et séparons les concepts.

Je nomme la valeur de retour de la requête XxxDto et évite d'utiliser le nom Dto ailleurs.

De plus, je le vois parfois mal compris.

*** CQRS ne signifie pas que vous ne pouvez pas effectuer de requêtes DB dans le modèle de domaine pour le traitement des mises à jour. *** ***

• Traitement des mises à jour → Interroger la base de données avec le modèle de domaine et mettre à jour la base de données avec le même modèle
• Traitement de référence → Requête DB avec modèle de requête

C'est la différence. S'il vous plaît soyez prudente.

Comment interagir avec un objet de domaine avec un mappeur OR
Actuellement, jooq est utilisé pour implémenter la persistance et le chargement à partir de DB. Existe-t-il un moyen d'omettre l'implémentation?

En ce qui concerne l'ORM du modèle de domaine, SpringDataJPA est un concept qui est tout à fait conscient de la conception axée sur le domaine, et puisque la classe d'implémentation de Repository est automatiquement générée à partir d'Interface, le problème peut être évité dans une certaine mesure. Cependant, ce sera un combat contre les spécifications d'hibernation, donc vous l'aimerez.

Je pense que l'avantage de l'interrogation est que vous pouvez réellement effectuer des requêtes efficaces vous-même, donc je ne pense pas que vous puissiez omettre la partie requête. Si vous utilisez MyBatis, le mappage entre la requête et l'objet qui la reçoit sera assisté dans une certaine mesure.

Objectif de la conception axée sur le domaine

Je ne connais que la joie de la conception axée sur le domaine.
Quelle est la priorité à protéger?

Quel type d'avantages est la priorité? J'écrirai plus à ce sujet dans un autre article, mais je vais juste vous donner un aperçu.

Premièrement, la conception axée sur le domaine n'est pas appropriée et convient aux «applications avec une logique métier complexe». Il y a beaucoup de frais généraux dans les cas où un simple CRUD suffit.

Pour les applications avec une logique métier complexe, le code source a tendance à devenir compliqué et l'efficacité du développement a tendance à diminuer à mesure que le développement progresse. D'un autre côté, je pense que la conception axée sur le domaine est une contre-mesure pour contrôler les spécifications complexes et bien coder.

Tout d'abord, décidons si cela répond à cet objectif.

De quoi vous souciez-vous lors du développement?

Pensez-vous que le modèle est correct

Le message de la conception axée sur le domaine est de se concentrer de toute façon sur le modèle.

Donc, je ne dis pas "rendre la modélisation appropriée et proposer quelque chose qui fonctionne pour le moment", mais juste se concentrer sur la question de savoir si le modèle semble correct.

Quelle couche est responsable de la mise en œuvre

C'est un point controversé lors de la conception.

Selon la définition de responsabilité de la couche domaine et de la couche application, «Où dois-je écrire cette implémentation?» Est naturellement guidé dans une certaine mesure. Vous devriez toujours y penser pendant le développement, et cela créera une politique de conception solide qui aidera à améliorer la maintenance de l'implémentation.

Responsabilités de la couche

La compréhension ici est ambiguë, alors dites-moi comment bien la séparer.

Je voudrais écrire cela en détail dans un autre article.

• Couche de domaine: assurer l'intégrité de l'entreprise à systématiser
• Modèle de domaine: représente le résultat de la modélisation d'une entreprise   * Entity   * ValueObject   * DomainEvent
• Service de domaine
• Référentiel: modèle de persistance / restauration des objets à partir de la destination de persistance
• Usine: création d'objets (choses complexes qui ne peuvent pas être laissées à l'entité)
• DomainService: Responsable de ne pas pouvoir s'exprimer comme un seul modèle
• Couche d'application
• Service d'application: répondez aux spécifications en combinant les opérations publiées par la couche de domaine

Libre de procéder au développement

Quel type d'accord avez-vous lors de l'introduction de la conception axée sur le domaine dans votre projet?

C'est un service interne. .. Cependant, étant donné que mon emploi précédent était au SIer, je répondrai sur la base de cette expérience.

Tout d'abord, s'il ne s'agit que d'architecture, devons-nous obtenir votre permission pour choisir l'architecture à adopter? Je pense que c'est le seul point. S'il n'y a pas de problème, vous pouvez éventuellement adopter une architecture de conception basée sur le domaine.

Le problème concerne le processus de développement. Une communication fréquente est requise car on dit que la conception axée sur le domaine doit toujours correspondre à la reconnaissance par le dialogue avec l'expert du domaine (≒ client). Il est nécessaire de convenir avec le client si cette opportunité peut être rentable.

Cependant, bien qu'il s'agisse d'une opinion personnelle complète, il n'est pas nécessaire de déclarer explicitement que «nous allons faire de la conception axée sur le domaine», et nous avons convenu de l'histoire que «je veux être conscient de cela, j'ai besoin de cette fréquence». Je pense que c'est bon de le prendre. Même les ingénieurs ont du mal à comprendre la conception axée sur le domaine, donc pour le moment, je pense qu'il est difficile de faire comprendre cela à la partie commerciale.

Que faites-vous pour partager le modèle avec vos clients?

Le diagramme ER est toujours maintenu, mais il n'y a que 3 ingénieurs.

Je ne partage pas l'honnêteté avec le côté commercial. J'avais l'habitude de travailler avec le planificateur au moment du nouveau développement, mais je ne correspondais pas beaucoup lorsque je continuais.

Si quoi que ce soit, il s'agit simplement de "faire correspondre les mots que nous utilisons" (≒ langage omniprésent). Pour être honnête, je ne connais pas l'image du partage du diagramme de modèle avec des gens du côté des entreprises, et après tout, la reconnaissance à l'écran est la meilleure, alors j'explore ce qui est bon à ce sujet.

Sourcing événementiel

L'avez-vous présenté? C'est OK?

Je ne l'ai pas encore fait.

L'approvisionnement en événements ne convient absolument pas aux données, vous devez donc prendre une décision en fonction de cela.

Par exemple, l'historique des achats, etc.

• Zone où les dégâts sont importants en cas de problème
• Type de transaction qui laisse des données

Convient à. Il n'est pas nécessaire d'effectuer un traitement simple tel que l'achèvement / l'achèvement de tâches dans le sourcing d'événements, et il est nécessaire d'identifier les avantages et les inconvénients.

À propos des sous-domaines

Je pense utiliser keycloak. Keycloak doit-il être traité comme un contexte délimité distinct?

Je pense qu'il vaut mieux penser à ce domaine à la fois à partir de l'image de mise en œuvre et du modèle conceptuel. C'est certainement un contexte différent si vous le rendez indépendant en tant que serveur d'authentification.
Dans ce cas, comment modéliser les informations reçues de celui-ci. Déterminez si la persistance est nécessaire.

À propos de l'architecture

Comment faire le modèle d'architecture trois couches + domaine?

Je recommande personnellement l'architecture d'oignon. Veuillez consulter l'article suivant pour plus de détails.

Quelle est l'architecture la plus accessible pour démarrer avec la conception pilotée par domaine

Présentation de l'architecture Domain Driven + Onion

Mais en substance

*** Si le modèle de domaine est écrit sous une forme qui ne dépend de rien, le reste est une erreur ***

est. Après cela, j'aimerais que vous choisissiez celui qui correspond à la structure et aux termes.

Comment créer un objet de domaine à partir des paramètres reçus de la couche d'interface utilisateur

Tout d'abord, créons des objets uniquement dans les deux modèles suivants.

• Lors de la création d'un nouveau: Il est recommandé de le créer normalement avec le constructeur de l'objet.
• Lors de la régénération d'un objet persistant à partir de la base de données: implémenté dans le référentiel. Il vaut mieux utiliser une sorte de cadre ici.

L'important est que *** les objets persistants ne doivent pas être créés avec les valeurs d'entrée de l'écran ***. Souvent, la méthode de mise à jour reçoit la valeur du formulaire d'écran et la remplit du constructeur par défaut.

Pour la couche de domaine, veillez à exposer uniquement les méthodes qui peuvent assurer la cohérence de la couche d'application.