it-swarm.com.de

Was ist die beste Vorgehensweise bei der Benennung von Microservices?

Ich komme aus einer "monolithischen" SOA API-Denkweise, in der es beispielsweise nur einen RESTful-Dienst für Persistenz geben würde (Persistenz-App). Jetzt, da ich mich in einer Microservice-Umgebung entwickle, Ich glaube, es ist am besten, den großen monolithischen Dienst in mehrere unabhängige Mikrodienste weiter zu entkoppeln, wie zum Beispiel:

  • DAO-Schicht (jede Entität hat ihren eigenen Microservice, z. B. Benutzer-App, Bestell-App, Artikel-App)
  • Validierungsschicht (Validierung, um zu überprüfen, ob die Anforderung beispielsweise eine Entität erstellt)
  • Geschäftslogikschicht (Angenommen, wir erstellen einen Auftrag für einen Kunden, es sollte einen anderen Microservice geben, der auf die DAO-Microservices zugreift.)

Also vom alten Ansatz: Client -> Persistenz-App ...

Jetzt wäre es: Client -> Validierungsschicht -> Geschäftslogikschicht -> DAO-Schicht.

Meine Frage ist, wie ich diese Microservices benenne. Früher war es nur ein Name und es war im Grunde "Persistence-App". Was ist die beste Vorgehensweise, um diese zu benennen, nachdem wir sie in viel definierte Dienste mit eigenen Funktionen entkoppelt haben? "User-Service", User-Validation-Service "," User-Order-Logic-Service "?

9
mpmp

Wenn ich Ihre Frage lese, bin ich mir nicht sicher, ob Sie genauso über Microservices denken wie ich.

Zum Beispiel würde ich niemals einen Validierungsmikroservice erstellen. Theoretisch kann ich sicher sehen, dass es funktioniert, aber wenn Sie Ihre AddUser () -Methode in Ihrem UserService haben, wird der Validierungsdienst für diese bestimmte Aktion immer aufgerufen, oder?

Das Trennen der Validierungslogik ist gut und schön, aber wenn nichts anderes es jemals nennen wird, würde ich diesen Code nicht als Service verfügbar machen.

Ich sehe Microservices als vertikale Schichten, wenn Ihr Monolith eher als horizontale Schichten, die Sie möglicherweise bereits haben.

Für mich ist die Benennung also einfach. UserService, OrderService usw. Vielleicht haben wir einen komplexen Fall, in dem Sie diese weiter aufteilen können, aber die Benennung ergibt sich aus der Logik, die die Aufteilung vorschlägt. dh AdminUserService/UserService

Offensichtlich haben Sie möglicherweise einen Fall, in dem zwei Dienste eine interne Logik gemeinsam haben und es nicht sinnvoll ist, diese in einen eigenen Dienst aufzuteilen. Aber auch hier ist die Benennung eher aus dem Zweck des Codes als aus der Ebene ersichtlich. Das heißt, AccountService und OrderService können beide OrderPricingService aufrufen.

Lassen Sie sich außerdem nicht vom Word-Dienst hängen. Ein UserRepository ist ein Repository, unabhängig davon, ob Sie über http oder im Speicher darauf zugreifen.

Werfen Sie auch nicht alle Ihre OOP -Objekte mit ihrer Geschäftslogik weg und machen Sie alles prozedural, es sei denn, es macht Sinn. Sie können Ihre Dienste Objekte instanziieren lassen und ihre Methoden in einem hochrangigen Mikroservice aufrufen als sie alle in einzelne OrderBusinessLogicService.ProcessOrder (Order o) -Dienste umzuwandeln

11
Ewan