Qual è la migliore pratica in merito alla denominazione dei microservizi?

Question

Qual è la migliore pratica in merito alla denominazione dei microservizi?

#1 da (8 voti)

4

Vengo da una mentalità dell'API SOA "monolitico" dove, diciamo, ci sarebbe solo un servizio RESTful per la persistenza (persistence-app). Ora che sto sviluppando in un ambiente di microservizi, ritengo sia meglio disaccoppiare ulteriormente il grande servizio monolitico in diversi microservizi indipendenti come:

Livello DAO (ogni entità ha il proprio microservizio, ad esempio user-app, order-app, item-app)
Livello di convalida (convalida per verificare se la richiesta, ad esempio, crea un'entità)
Livello logico aziendale (supponiamo di dover creare un ordine per un cliente, dovrebbe esserci un altro microservizio che accede ai microservizi DAO)

Quindi dal vecchio approccio: Client - > la persistenza-app ...

Ora sarebbe: Client - > livello di validazione - > livello di logica aziendale - > Livello DAO.

La mia domanda è come denominare questi microservizi? Prima, era solo un nome ed era fondamentalmente "persistence-app". Ora che l'abbiamo disaccoppiato in servizi molto più definiti con le loro funzioni, qual è la migliore pratica per nominarli? "user-service", user-validation-service "," user-order-logic-service "?

microservices naming-standards

posta mpmp 10.05.2017 - 18:54

fonte

1 risposta

Leggi altre domande sui tag microservices naming-standards

Conservo i post del blog in un database? E come posso continuare a pubblicare post? È possibile che readmodel e writemodel ereditino dal modello per i campi in DDD + CQRS?

score 8 · Accepted Answer

Leggendo la tua domanda non sono sicuro che stai pensando ai microservizi allo stesso modo di me.

Ad esempio, non creerei mai un microservizio di convalida. In teoria, posso vedere che potrebbe funzionare, ma diciamo che hai il tuo metodo AddUser () sul tuo UserService, la sua sempre gona chiama il servizio di validazione per quella particolare azione giusto?

Separare la logica di validazione va bene, ma se non lo chiameresti mai, non lo esporrò come servizio.

Vedo i microservizi come sezioni verticali se il tuo monolite piuttosto che i livelli orizzontali, che potresti già avere.

Quindi per me la denominazione è facile. UserService, OrderService ecc. Forse abbiamo un caso complesso in cui è possibile suddividerli ulteriormente, ma la denominazione sarà chiara dalla logica che suggerisce la scissione. cioè AdminUserService / UserService

Ovviamente potresti avere un caso in cui due servizi condividono una logica interna e non ha senso dividerlo nel proprio servizio. Ma ancora una volta, la denominazione è chiara dallo scopo del codice piuttosto che dal livello. Ad esempio, AccountService e OrderService potrebbero chiamare OrderPricingService.

Inoltre non rimanere appeso alla parola 'servizio' un UserRepository è un repository se lo si accede tramite http o in memoria.

Inoltre, non buttare via tutti gli oggetti OOP con la loro logica aziendale e rendere tutto procedurale a meno che non abbia senso. Puoi fare in modo che i tuoi servizi instanzino gli oggetti e chiamino i loro metodi in un microservice di alto livello piuttosto che convertirli tutti in singoli servizi OrderBusinessLogicService.ProcessOrder (Order o)