Quelle est la meilleure pratique en matière de dénomination des microservices?
Je viens d'un état d'esprit "monolithique" SOA API où, disons, il n'y aurait qu'un seul service RESTful pour la persistance (persistence-app). Maintenant que je développe dans un environnement de microservices, Je pense qu'il est préférable de découpler davantage le grand service monolithique en plusieurs microservices indépendants tels que:
- Couche DAO (chaque entité possède son propre microservice, par exemple, application utilisateur, application de commande, application d'article)
- Couche de validation (validation pour vérifier si la demande, par exemple, de créer une entité)
- Couche logique métier (supposons que nous devions créer une commande pour un client, il devrait y avoir un autre microservice qui accède aux microservices DAO)
Donc, de l'ancienne approche: Client -> persistence-app ...
Maintenant, ce serait: Client -> couche de validation -> couche logique métier -> couche DAO.
Ma question est de savoir comment nommer ces microservices? Avant, c'était juste un nom et c'était essentiellement "persistence-app". Maintenant que nous l'avons découplé en services beaucoup plus définis avec leurs propres fonctions, quelle est la meilleure pratique pour les nommer? "service-utilisateur", service-validation-utilisateur "," service-logique-commande-utilisateur "?
En lisant votre question, je ne suis pas sûr que vous pensiez aux microservices de la même manière que moi.
Par exemple, je ne créerais jamais de microservice de validation. En théorie, bien sûr, je peux voir que cela pourrait fonctionner, mais disons que vous avez votre méthode AddUser () sur votre UserService, il est toujours nécessaire d'appeler le service de validation pour cette action particulière, n'est-ce pas?
Séparer la logique de validation est très bien, mais si rien d'autre ne l'appelle, je ne l'exposerais pas comme un service.
Je vois les microservices comme des tranches verticales si votre monolithe plutôt que des couches horizontales, que vous avez peut-être déjà.
Donc pour moi, le nommage est facile. UserService, OrderService etc. peut-être avons-nous un cas complexe où vous pouvez les diviser davantage, mais la dénomination sera claire d'après la logique qui suggère la division. c'est-à-dire AdminUserService/UserService
Évidemment, vous pouvez avoir un cas où deux services partagent une logique interne et il est logique de diviser cela en son propre service. Mais encore une fois, la dénomination ressort clairement de l'objectif du code plutôt que de la couche. ie AccountService et OrderService peuvent tous deux appeler OrderPricingService.
De plus, ne vous bloquez pas sur le "service" de Word, un UserRepository est un référentiel, que vous y accédiez via http ou en mémoire.
Aussi, ne jetez pas tous vos objets OOP avec leur logique métier et faites tout ce qui est procédural à moins que cela ait du sens. Vous pouvez demander à vos services d'instancier des objets et d'appeler leurs méthodes dans un microservice de haut niveau plutôt que de les convertir tous en services OrderBusinessLogicService.ProcessOrder (Order o) individuels