Naming is critical to the human comprehension of your system, and this obviously extends to service naming. Human comprehension is king and so in order to fight the biggest limiting factor on your software system accepting and thriving on change, i.e. you and your comprehension of it, naming is a critical concern.
When naming microservices I recommend you focus on naming a service in terms of what it does, not what it is. PayrollSummaryAggregator, or “PayrollTableView” are named in this preferred way.
Things to avoid include (in no particular order as such):
If you find yourself developing a service and wanting to use “and’ in the title then it’s a good indication that the service is going to much. This is a good and natural thing; we often build services that start out seeming to do one thing and then realise that it does too much, which leads to reduction and new service extraction.
What about Type?
Calling a service a “Service does not make it a single-concern service that aids comprehension.*
Should you add “Service” to a service’s name? The rule here is only if you have other *types’ of artefact in your system.
If you have stable and reusable libraries then having some things called “Library” and others called “Service” probably aids understanding.
But use a type with care, it can easily lead to too high-level and name and hide multiple concerns and complexity in the service.
A Word on Codenames
Code naming services is fun and often used when we’re not sure what a service will do … yet. However these should be dropped at the earliest opportunity as they:
Avoiding Acronyms, IYC (If You Can)
The danger of naming micro services with what they do is that it can lead to long service names. That in itself is not a problem, but it can lead us lazy humans to strip them down to acronyms in conversation (both digital and verbal), which then leads to reducing the comprehension of others.
Try to avoid acronymising service names, even if they are long unless you are in a context where the acronym has been clarified.
When naming microservices I recommend you focus on naming a service in terms of what it does, not what it is. PayrollSummaryAggregator, or “PayrollTableView” are named in this preferred way.
Things to avoid include (in no particular order as such):
- Avoiding nouns
- Avoiding ‘and’ in the name
- Avoiding codenames!!!
- Avoiding Acronyms
If you find yourself developing a service and wanting to use “and’ in the title then it’s a good indication that the service is going to much. This is a good and natural thing; we often build services that start out seeming to do one thing and then realise that it does too much, which leads to reduction and new service extraction.
What about Type?
Calling a service a “Service does not make it a single-concern service that aids comprehension.*
Should you add “Service” to a service’s name? The rule here is only if you have other *types’ of artefact in your system.
If you have stable and reusable libraries then having some things called “Library” and others called “Service” probably aids understanding.
But use a type with care, it can easily lead to too high-level and name and hide multiple concerns and complexity in the service.
A Word on Codenames
Code naming services is fun and often used when we’re not sure what a service will do … yet. However these should be dropped at the earliest opportunity as they:
- Provide a way of hiding a service that does too much
Avoiding Acronyms, IYC (If You Can)
The danger of naming micro services with what they do is that it can lead to long service names. That in itself is not a problem, but it can lead us lazy humans to strip them down to acronyms in conversation (both digital and verbal), which then leads to reducing the comprehension of others.
Try to avoid acronymising service names, even if they are long unless you are in a context where the acronym has been clarified.
RSS Feed
