Article de la série: Série de commentaires sur la conception axée sur le domaine
Quelle est l'architecture la plus accessible pour commencer à mettre en œuvre avec la conception axée sur le domaine - laboratoire des petites mains
Domain Driven + Onion Architecture Overview --little hands 'lab
Comme je l'ai écrit dans ces articles, je suis DDD Nous utilisons le terme architecture d'oignon pour décider de l'architecture en couches de. Je l'ai expliqué à diverses personnes jusqu'à présent, et j'ai parlé des responsabilités de couche comme un point qui permet de rester facilement coincé dans la compréhension, alors je vais l'expliquer.
Onion Architecture Is Interesting - DZone Java
Description de chaque couche écrite dans cet article
Traduction en japonais
Je l'ai expliqué à diverses personnes jusqu'à présent, mais dans de nombreux cas, je ne pouvais pas faire les choses correctement avec l'explication ci-dessus. Surtout quand il s'agit de *** logique spécifique à une application ***, le mot «application» est ambigu, donc les gens le perçoivent différemment, et il ne semble pas convenir.
Par conséquent, récemment, je me suis concentré sur le thème des responsabilités et j'ai essayé d'expliquer comme suit.
Il peut être un peu trompeur ou contre-argumentant de dire que la responsabilité de la couche de domaine est "l'intégrité des données", mais j'ose le dire en mettant l'accent sur la facilité de communication.
Je vais vous expliquer en détail ci-dessous.
Que signifie «garantir l'intégrité des données» à cette couche?
Pour un exemple de code concret, veuillez vous référer à l'article Qu'est-ce qu'exprimer la connaissance du domaine dans un modèle. Cependant, nous visons à «exposer uniquement les méthodes qui peuvent assurer la cohérence aux couches supérieures (ne pas rendre la visibilité publique).
Dans l'exemple de l'article ci-dessus, la règle d'intégrité des données est qu '«une tâche ne peut être reportée que trois fois, un jour à la fois». Afin de garantir cela, il est nécessaire d'effectuer des contrôles tels que «enregistrer le nombre de reports lors du report d'une tâche» et «vérifier le nombre de reports jusqu'à présent avant de reporter et faire une erreur s'il dépasse 3 fois».
Une méthode qui ne garantit pas cela est quelque chose comme "Vous pouvez modifier librement la date d'échéance sans tenir compte du nombre de reports de tâches". C'est exactement ce à quoi tous les setters sont exposés dans le paramètre public, comme les objets de modèle ActiveRecord.
En ne rendant publiques que les méthodes qui peuvent être contrôlées correctement, nous visons un état où «quelle que soit la dureté de la couche supérieure, l'intégrité des données ne peut pas être rompue».
J'ai écrit que la responsabilité de cette couche est de "combiner les méthodes exposées par la couche de domaine et d'assembler un cas d'utilisation".
En quoi est-ce différent des responsabilités de la couche de domaine?
Pour donner un autre exemple, disons que la couche de domaine expose une "méthode pour changer l'adresse d'un utilisateur" et une "méthode pour changer un numéro de téléphone fixe" comme méthodes publiques indépendantes.
Cela signifie que la couche de domaine "permet à l'adresse et au numéro de téléphone fixe d'être mis à jour indépendamment pour des raisons d'intégrité des données".
D'autre part, dans la couche application, les cas d'utilisation suivants peuvent être réalisés en combinant les méthodes ci-dessus.
Que vous souhaitiez que l'opération de mise à jour soit effectuée indépendamment ou en même temps peut être librement combinée dans la couche d'application en fonction du cas d'utilisation que vous souhaitez réaliser.
À l'inverse, si la couche de domaine dit: «Pour l'intégrité des données, les adresses et les numéros de téléphone fixes ne peuvent être mis à jour qu'en même temps», la couche d'application devra se conformer.
Les cas d'utilisation (en particulier dans vos propres applications Web) peuvent changer en un cycle court en fonction de votre stratégie. Mais l'intégrité des données changera-t-elle en conséquence? La réponse serait non. En confinant des éléments avec des cycles de vie différents dans chaque couche, vous pouvez rendre la conception résistante au changement.
Enfin, je voudrais écrire sur les mérites de la raison pour laquelle une telle superposition est effectuée.
Lors de la conception d'un DDD, il est toujours nécessaire de se demander "où est ce processus responsable?" C'est un concept très important qui est au cœur de la conception de couches de DDD. Veuillez l'utiliser comme référence lors de la conception.
Recommended Posts