2017-07-09 2 views
0

Je DTO et modèles DOMAIN:La meilleure façon de cartographie DTO/domaine pour le transport entre microservices

@Data 
public class CarDomain { 
    private String name; 
    private int year; 
    private String color; 
} 

et

@Data 
public class CarDto { 
    private String name; 
    private int year; 
    private String color; 
} 

J'ai 3 microservices (MS) communiquent entre eux par rabbitmq. J'ai models module avec toutes les classes DTO. Chaque MS comprend models module dans maven.

1 MS envoyer carDto 2 MS reçoit CarDto et le convertit en domaine. Pour cela, je peux utiliser plusieurs variantes:

  1. bibliothèque utilisation par exemple mapstruct:
@Mapper 
public interface CarMapper { 
    CarMapper INSTANCE = Mappers.getMapper(CarMapper.class); 
    CarDto carToCarDto(CarDomain car); 
} 

et utilisation:

CarDto carDto = CarMapper.INSTANCE.carToCarDto(carDomain); 
  1. Créer mapper manuel:
class CarMapper { 
     public static CarDto toDto(CarDomain car) { 
      CarDto carDto = new CarDto(); 
      carDto.setName(car.getName()); 
      carDto.setYear(car.getYear()); 
      carDto.setColor(car.getColor()); 
     } 
    } 

Maintenant, nous utilisons deux variantes. Nous sommes quand nous construisons microservice et dans models module un certain champ de changement de modèle DTO nous obtenons une erreur sur le temps de compilation. Par exemple le nom de quelqu'un changer ce modèle dpour dans models module

private String name; 

à

private String name1; 

Quand nous construisons projet, nous obtenons une erreur sur cette ligne:

carDto.setName(car.getName());// getName not found becose now getName1 

Mais cette dure. Pour chaque modèle dto/domaine, nous devons créer un mappeur et écrire chaque champ. Dans 1 variantes c'est plus facile mais si vous changez, nous obtenons une erreur à l'exécution. Dites-moi la meilleure approche pour faire correspondre/cartographier les modèles dto/domaine?

+0

Si vous ne l'avez pas déjà fait, consultez cette vidéo: https://www.youtube.com/watch?v=yPvef9R3k-M –

Répondre

3

Lorsque nous construisons un module microservice et que nous modélisons un champ du changement de modèle DTO, nous obtenons une erreur au moment de la compilation.

Le problème auquel vous êtes confronté est généralement reconnu en tant que versionnage de message.

Une idée clé dans les microservices est qu'ils peuvent être redéployés indépendamment les uns des autres; vous devriez être capable de les changer à tout moment sans casser tout le reste. Pour ce faire, nous limitons le couplage entre les microservices aux messages qu'ils ont en commun.

En conséquence de ceci; il s'ensuit que c'est vraiment important pour obtenir les schémas de message "à droite".Dans ce cas, cela ne signifie pas que vous devinez les messages corrects à envoyer pour la première fois, mais plutôt que vous investissez du capital initial pour comprendre comment les messages changent et quelles structures de messages prennent en charge ces changements.

La meilleure référence unique sur le sujet que je connais est le livre de Greg Young Versioning in an Event Sourced System. Greg fait valoir la nécessité d'utiliser des «schémas faibles» pour prendre en charge la compatibilité ascendante et descendante; les idées de base sont

  • La signification d'un champ ne change jamais
  • Le consommateur doit ignorer et doit transmettre des champs, il ne comprend pas
  • La plupart (tous?) les champs doivent être facultatif; le consommateur doit être préparé pour l'événement qu'un élément de données manque dans le message. Cela peut signifier avoir préparé une valeur par défaut acceptable ou un traitement alternatif.

Avec les bases à l'esprit; vous pouvez regarder les détails de Avro, Thrift, Protocol Buffers pour avoir une idée de la façon dont les formats standardisés ont tendance à évoluer. La discussion de Martin Kleppmann sur Schema Evolution in Avro, Protocol Buffers, and Thrift pourrait être une bonne étape intermédiaire.

La discipline de message est vraiment importante - le schéma fait partie de l'API du microservice. L'introduction d'un changement incompatible vers l'API introduit beaucoup de risques et ne devrait pas être entreprise à la légère.

J'ai un module de modèles avec toutes les classes DTO.

Cela peut être une erreur; c'est difficile à dire. C'est certainement une erreur d'avoir un noyau commun qui évolue régulièrement d'une manière qui n'est pas rétrocompatible. Cette habitude devrait changer.