Modèle de domaine exposé dans l'architecture de microservice Java
Je suis conscient que la copie des classes et des propriétés d'entité dans les DTO est considérée comme anti-pattern, donc par Exposed domain model pattern le même @Entity peut être utilisé à la fois comme classe d'entité de base de données et comme DTO pour le service et la couche MVC. (voir ici https://codereview.stackexchange.com/questions/93511/data-transfer-objects-vs-entities-in-java-rest-server-application)
Mais supposons que nous ayons une architecture microservice où le même ensemble de propriétés est utilisé comme entité dans un projet avec persistance, et comme DTO dans un autre projet qui utilise le premier en tant que service. Quel est le modèle proposé dans une telle situation?
Parce que le deuxième projet n'a pas besoin de fonctionnalités liées à @Entity, et si nous mettons cette classe dans une bibliothèque partagée, elle sera liée inutilement aux API et bibliothèques spécifiques à JPA. Et l'alternative est d'utiliser à nouveau des classes DTO séparées anti-pattern.
2 answers
Lorsque vos exigences pour un modèle DTO correspondent exactement à votre modèle d'entité, vous êtes soit à un stade très précoce du projet, soit très chanceux d'avoir un modèle simple. Si votre modèle est très simple, les DTO ne vous donneront pas beaucoup d'avantages immédiats.
À un moment donné, les exigences pour le modèle DTO et le modèle d'entité divergeront cependant. Imaginez que vous ajoutiez des aspects d'audit, des statistiques ou une dénormalisation à votre modèle d'entité/persistance. Ce type de données n'est généralement jamais exposé via DTO directement, vous devrez donc diviser les modèles. Il est également souvent le cas que le principal moteur pour les DTO est le fait que vous n'avez pas besoin de toutes les données tout le temps. Si vous affichez des objets dans une liste déroulante, par exemple, vous n'avez besoin que d'une étiquette et de l'id d'objet, alors pourquoi chargeriez-vous l'état entier de l'entité pour un tel cas d'utilisation?
Le fait que vous ayez des annotations sur vos modèles DTO ne devrait pas vous déranger tant que ça, quelle est l'alternative? Un mappage de type XML? Câblage manuel d'objet? Si votre modèle est utilisé directement par des tiers, vous pouvez utiliser une sous-classe, c'est-à-dire garder le modèle principal exempt d'annotations et avoir des sous-classes annotées dans votre projet qui étendent le modèle principal.
Depuis l'implémentation correcte d'une approche DTO, j'ai crééBlaze-Persistence Entity Views qui simplifiera non seulement la façon dont vous définissez les DTO, mais améliorera également les performances de vos requêtes.
Si vous êtes intéressé, j'ai même un exemple pour un externe le modèle utilise entité afficher les sous-classes pour garder le principal modèle propre.
Merci pour les réponses, mais soulignez dans la question est sur l'architecture microservice (MS) et la réutilisation des POJOs d'entité définie d'un MS dans un autre comme POJOs. D'après ce que j'ai lu sur microservices, il est étroitement lié à une autre question - MSs devrait-il partager des fonctionnalités et des classes communes, ou être complètement indépendant? Il semble qu "il n" y ait pas d " accord définitif à ce sujet, et aussi pas de réponse définitive, ou modèle largement accepté, à cela.
De mon expérience récente voici ce que j'ai adopté, et cela fonctionne bien jusqu'à présent. Avoir des fonctionnalités communes à travers MSs-oui, sous la forme d'un projet commons ajouté en tant que dépendance à tous les MSs, avec ses dépendances définies comme facultatives. Partager les classes d'entités (les exposer dans commons) - non.
La raison principale est que les classes d'entités sont étroitement liées au magasin de données pour MS particulier Et comme la règle établie est que MSs ne doit pas partager les magasins de données, il est logique de ne pas partager les classes d'entités pour ces magasins de données. Il aide MSs à être plus indépendant, et la liberté de gérer leur magasin de données à leur manière. Cela signifie un peu plus de frappe pour ajouter des classes DTO supplémentaires et la conversion entre elles, mais c'est un compromis qui vaut la peine d'être pris pour conserver l'indépendance de MS. Les raisons mentionnées par Christian Beikov et Maksim Gumerov s'appliquent également.
Ce que nous partageons (mis en commun) sont des fonctionnalités communes et des classes d'assistance (pour le cloud, la découverte, la gestion des erreurs, la configuration rest et json...), et DTO purs, où T est transfert entre MSs (entités rest ou charges utiles de message).