[JAVA] [DDD] Quelle est l'architecture la plus accessible pour démarrer avec la conception pilotée par domaine?

Article sérialisé DDD

• Pourquoi les débutants DDD sont-ils déçus tout de suite
• Que dit Eric Evans de la définition de la conception pilotée par domaine
• Quelle est l'expression de la connaissance du domaine dans un modèle
• Quelle est l'architecture la plus accessible à mettre en œuvre avec une conception axée sur le domaine
• Présentation de l'architecture Domain Driven + Onion

Contexte / prémisse

Dans l'article Pourquoi les débutants DDD sont déçus immédiatement après s'en être débarrassés

Il existe différentes architectures introduites dans la littérature sur le net. L'architecture hexagonale a été mentionnée dans IDDD, mais il existe des variantes célèbres telles que l'architecture d'oignon et l'architecture propre qui en ont évolué. Cela crée beaucoup de confusion lors de la mise en œuvre. Vous passerez du temps à comprendre le contexte et à choisir l'architecture à adopter.

J'ai écrit. Voici une architecture que je considère comme la "plus accessible".

En tant que prémisse, *** est une opinion personnelle *** entièrement basée sur l'expérience personnelle.

Dans la théorie du DDD, concernant l'architecture, Conception basée sur le domaine d'Eric Evans <img src =" // ir-jp.amazon-adsystem.com/e/ir?t=majackyy-22&l=am2&l=am2 = 9 & a = 4798121967 "width =" 1 "height =" 1 "border =" 0 "alt =" "style =" border: none! Important; margin: 0px! Important; "/> (le texte original ci-dessous) et <une cible = "_ blank" href = "https://www.amazon.co.jp/gp/product/479813161X/ref=as_li_tl?ie=UTF8&camp=247&creative=1211&creativeASIN=479813161X&linkCode=as2&tag=ma068jacke-22&blinkcode=as2&tag=ma068jacke-22&bb12cId6 Conception du lecteur (SELECTION orientée objet) (Ci-après IDDD) et d'autres sont introduits, et on dit que c'est la seule bonne réponse. Rien n'est présenté. L'architecture est laissée à la discrétion de chaque projet et l'adéquation dépend des exigences et des membres du projet.

Cependant, je pense que ça va me faire me demander comment commencer quand je débute, alors je vais proposer * "Si un débutant commence, c'est bien" *. Notez s'il vous plaît.

Architectures candidates et leurs relations

Si vous regardez des articles DDD en ligne, vous trouverez ce qui suit.

1. Architecture en couches
2. Architecture hexagonale
3. Architecture d'oignon
4. Architecture propre

Permettez-moi de vous en donner un bref aperçu.

Architecture en couches

L'architecture introduite dans le texte original. Par rapport à l'architecture conventionnelle à trois couches, l'idée est d'établir une couche de domaine et d'y agréger la logique de domaine.

Architecture hexagonale

L'architecture introduite dans IDDD. Aussi connu sous le nom d '«architecture de port et d'adaptateur». Il a été proposé à l'origine en 2005 par ce blog.

En fait, *** «Hexagonal, Onion, Clean» sont essentiellement les mêmes ***.

L'idée est qu'il est complété par cet hexagonal. La façon dont les responsabilités sont séparées et le nom sont légèrement différents. Alors, n'est-ce pas d'accord avec hexagonal?

Oui, il est essentiellement hexagonal et, par conséquent, il a le même design.

Cependant ...

*** L'image d'implémentation ne sort-elle pas même si vous regardez ce chiffre? *** ***

Je pense que c'est le point, et je me demande si cette confusion est la raison pour laquelle les gens qui lisent IDDD ne peuvent pas bouger leurs mains tout de suite.

Dans une position étrange, la conclusion est *** Ma recommandation est Onion Architecture ***. Bien que ce soit essentiellement la même chose, il est plus facile à comprendre intuitivement en raison du changement de la division des responsabilités et du nom, donc je pense qu'il est préférable de faire la première introduction en regardant ce chiffre.

Ensuite, je vais vous présenter cela.

Architecture d'oignon

Suivant l'architecture hexagonale, l'architecture oignon a été proposée dans ce blog en 2008.

N'y a-t-il pas une image de quel genre de structure ce sera? J'expliquerai les détails plus tard, mais le fait est que la couche Domaine ne dépend plus de la couche Infrastructure en raison du principe de l'inversion des dépendances ***. Cela fait du modèle de couche de domaine une implémentation qui ne dépend pas d'une bibliothèque spécifique.

C'est exactement la même idée dans l'architecture hexagonale, mais elle est difficile à lire à partir du diagramme conceptuel. C'est pourquoi je recommande l'architecture d'oignon pour commencer en raison de la clarté intuitive du diagramme.

C'est un ordre étrange, mais je vais également vous montrer une architecture propre à titre de comparaison.

Une architecture propre

Suivant les architectures hexagonale, oignon et autres, l'architecture épurée a cherché à intégrer les concepts en 2013. Il a été proposé dans ce blog.

L'image est tirée du même blog

Comme vous pouvez le voir sur la structure où les cercles concentriques se chevauchent, la même chose est essentiellement dite. Je pense que la seule différence est le mot.

Certains articles indiquent que l'architecture propre est utilisée comme architecture d'application Android indépendamment de DDD.

J'aime vraiment cela, mais il est difficile de comprendre ce qu'il faut écrire dans la couche appelée «couche de cas d'utilisation», et le nom est «couche d'entité» au lieu de «couche de domaine» (l'entité fait partie de la couche de domaine dans DDD) Donc ça ne rentre pas), donc je préfère l'architecture oignon.

Si cela vous convient, je pense que vous devriez adopter la dénomination de l'architecture propre.

Comment mettre en œuvre à l'aide de l'architecture

A propos de la façon d'intégrer le comportement dans la couche de domaine [DDD] Quelle est l'expression de la connaissance du domaine dans le modèle Cet article le présente avec un exemple de code.

L'entité Task de l'article correspond à DomainModel, TaskRepository correspond à DomainService et TaskApplication correspond à Application. En regardant les choses comme ça, c'est assez simple et je pense qu'il est facile d'imaginer le nom et le contenu de la couche.

C'est pourquoi j'essaie de commencer avec l'architecture oignon et l'exemple de code comme avant lorsque j'explique DDD pour la première fois.

Je voudrais approfondir un peu l'architecture de l'oignon et l'inversion des dépendances dans un autre article.

Article suivant

Présentation de l'architecture Domain Driven + Onion Jetez un œil ici.

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 5 Architecture" 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