13

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"?

Improve this question
1

1 Answer 1

Reset to default
15

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, it's 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 as a service.

I see microservices as vertical slices of 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 services share some internal logic and it 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 their business logic and make everything procedural unless it makes sense. You can have your services instantiate objects and call their methods in a high-level microservice rather than convert them all to individual OrderBusinessLogicService.ProcessOrder(Order o) services .

Improve this answer
1

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.