Les meilleures pratiques pour la publication de changements d'état d'une entité

Question

je modèle suivant:

public class Team { 
    public Guid Id {get; set;} 
    public string Name {get; set;} 
    public string League {get; get;} 
    public int Rating {get; set;} 
} 

Lors de la création d'une nouvelle équipe dans le système, je publie l'événement: TeamCreated au bus de service:

{ 
    "MessageId": "33909eaf-56a1-4467-a01a-64b94f10490c" 
    "MessageType": "TeamCreated", 
    "CreationDate": "20-01-2016", 
    "Payload": { 
     "Id": "11111www-56a1-4467-a01a-64b94f000111", 
     "Name": "Toronto Maple Leafs", 
     "League": "NHL NorthEast", 
     "Rating": 100 
    } 
} 

suivant que cette entrée a été modifiée pour ce qui suit:

{ 
    "MessageId": "33909eaf-56a1-4467-a01a-64b94f10490c" 
    "MessageType": "TeamUpdated", 
    "CreationDate": "20-01-2016", 
    "Payload": { 
     "Id": "11111www-56a1-4467-a01a-64b94f000111", 
     "Name": "Toronto Maple Leafs", 
     "League": "NHL NorthEast", 
     "Rating": 50 
    } 
} 

comme vous le voyez, il u Le message pdated contient toujours la valeur de toutes les propriétés et pas seulement la propriété modifiée qui est Rating de l'équipe.

Mon modèle, dans un système réel, possède plus de 50 propriétés et je ne souhaite pas créer d'événements distincts pour chaque propriété lors de sa mise à jour. Spécialement parce qu'il peut être le cas que plus d'une propriété a été modifiée dans une mise à jour.

Existe-t-il un modèle défini pour ce scénario dans l'architecture d'approvisionnement d'événements?

Answer 1

La réponse habituelle est d'abandonner les événements CRUD, et de décrire plutôt les changements en utilisant le langage omniprésent.

Dans une certaine mesure, il s'agit simplement d'un exercice de découplage; nous essayons de décrire "ce qui s'est passé" sans être trop investis dans la façon dont nous avons mis en place l'état de l'entité aujourd'hui.

Pour choisir un exemple; Supposons que les Leafs devaient déménager à Vegas; comment décririons-nous cela dans le langage omniprésent? Nous dirions probablement que l'équipe a déménagé (changement de ville, stade), réaligné (changement de ligue), et peut-être rebaptisé (changement de nom d'équipe, logo), éventuellement vendu (changement de groupe de propriété). Ainsi, plutôt que d'empaqueter ces données dans un événement TeamUpdated, nous nous attendons à voir le changement représenté comme plusieurs événements, avec le partage de données logiquement groupé l'événement approprié. Lorsque vous réhydratez l'entité, il lui incombe de reconnaître les données dans la charge utile de l'événement et de comprendre comment elle modifie son propre état (privé) pour refléter l'historique précédemment enregistré.