Types de données protobuf courants dans l'architecture de microservice?

Question

Nous envisageons de mettre en place une architecture de microservice. Nous aurons un logiciel géré par plusieurs équipes et nous utiliserons grpc avec protobuf 3 comme mécanisme de sérialisation pour la communication point à point. Le but est de découpler la logique métier de la logique applicative d'une part et de permettre aux interfaces utilisateur de couvrir plusieurs contextes métier d'autre part.

Les microservices devront parfois traiter des données similaires ou identiques aux données traitées par d'autres microservices.

Dans ce contexte, est-il conseillé d'extraire ces types de données proto3 courants, de les traiter séparément et de les importer en tant que dépendances dans chaque microservice? De cette façon, ils pourraient être réutilisés dans plusieurs services. Ou vaut-il mieux se concentrer sur le découplage des microservices les uns des autres en ne partageant aucun type de données (commun) (architecture sans partage)?

Answer 1

Ce qui devrait vous surprendre, c'est pourquoi plusieurs microservices traiteront des données similaires ou identiques. Cela peut signifier que vous allez trop loin en découpant votre solution. Citation Sam Newman - "contextes délimités représentent des domaines métier autonomes (c'est-à-dire, des capacités métier distinctes), et sont donc le point de départ approprié pour identifier les lignes de démarcation pour les microservices". Donc, je dirais - il devrait y avoir une bonne raison d'aller plus loin que le domaine d'activité -> la division des microservices. Un bon commentaire sur le "partage de bibliothèques/composants" J'ai lu récemment que bientôt cette bibliothèque/composant partagé devient votre goulot d'étranglement, toute modification que vous y apporterez nécessitera beaucoup de tests de régression entre équipes et la valeur initiale de il peut être éclipsé par l'effort nécessaire pour le maintenir.

Donc, comme vous pouvez le voir, si vous allez microservices, je voterais pour l'approche part rien ;-)