If I have microservice architecture and one or more microservices have layered architecture that contain service layer, how can I avoid naming confusion between microservices and structural units of an application called services?
What I've found useful:
Endpoints exposed to the outside world are Application Programming Interfaces (APIs). Jobs that run periodically are jobs. Things that listen for messages are message/event/command handlers/listeners, etc.
The nugget of code that implements the interesting bits that each of these use (regardless of the interface used to invoke it) is called the service.
You could try some workaround with some specific naming but this is just unlikely to be enough.
Just don't mix something of higher level in the architecture of your system (the micro service) with something of a lower level since it's a inner layer within a specific component of your system (the service/manager) when talking. Don't put them both in the same sentence.
Now if you need a way to differentiate them more strongly to reduce the confusion, then consider it as the following :
- A micro service is a service at a System level so you could named it "System service". Eventually if some part of your System aren't in micro services, with that way of naming, you don't need to differentiate them.
- The other one is a layer within one system component, so you could call it "Service layer".
Respecting that naming (or another if you find better) and not mixing them both together in the same sentences/explanations should be enough to avoid confusions.