What is the best practice when it comes to naming microservices?

Question

I come from a "monolithic" SOA API mindset where, lets say, there would only be one RESTful service for persistence (persistence-app). Now that I'm developing in a microservice environment, I believe it's best to further decouple the big monolithic service into several independent microservices such as:

• DAO layer (each entity has is its own microservice e.g. user-app, order-app, item-app)
• Validation layer (validation to check whether the request to, for example, create an entity)
• Business logic layer (assume we were to create an order for a customer, there should be another microservice that accesses the DAO microservices)

So from the old approach: Client -> persistence-app...

Now it would be: Client -> validation layer -> business logic layer -> DAO layer.

My question is how do I name these microservices? Before, it just used to be one name and it was basically "persistence-app". Now that we've decoupled it into much more defined services with their own functions, what's the best practice to name these? "user-service", user-validation-service", "user-order-logic-service"?

Answer 1

Reading your question I'm not sure you are thinking about microservices in the same way as me.

For example I would never create a validation microservice. In theory, sure I can see it might work, but say you have your AddUser() method on your UserService, its always gona call the validation service for that particular action right?

Separating out the validation logic is all well and good, but if nothing else is ever going to call it I wouldn't expose that code it as a service.

I see microservices as vertical slices if your monolith rather than horizontal layers, which you may already have.

So for me the naming is easy. UserService, OrderService etc perhaps we have a complex case where you can split these further, but the naming will be clear from the logic which suggest the split. ie AdminUserService/UserService

Obviously you may have a case where two service share some internal logic and ot makes sense to split that out into its own service. But again, the naming is clear from the purpose of the code rather than the layer. ie AccountService and OrderService might both call OrderPricingService.

Additionally don't get hung up on the word 'service' a UserRepository is a repository whether you access it via http or in memory.

Also, don't throw away all your OOP objects with thier business logic and make everything procedural unless it makes sense. You can have your services instanciate objects and call thier methods in a high level microservice rather than convert them all to individual OrderBusinessLogicService.ProcessOrder(Order o) services