> A well-factored service will generally have a tight set of responsibilities which make sense together, and this makes a descriptive name very appealing. Your service which started with a nice, tidy set of responsibilities may start to shift over time. And then you're faced with a choice: keep the old descriptive-but-now-wrong name, or put in all the effort to change it.
I had this happen recently. We wrote an application with two major components: one that processes events and repackages them as generic events and a component that receives those events and schedules work. We work in a compliance heavy environment so the architecture often reflects a separation of concerns given the information being processed.
The scheduler became pretty popular for people to plug into, even if they didn't use our other component. The scheduler eventually left the nest of our small, purpose-built program and became general infrastructure. It's now the "SecureScheduler", though on our component diagrams it simply goes by "scheduler".
My lesson learned was that if you properly separate an application out, the component names can become independent software in the service registry over time if they need to. The scheduler is pretty strictly scoped, so it'll never start doing new zaney things. It simply schedules work in a controlled environment.
These arguments over cute and functional names, I think, are a byproduct of a couple failures:
- Properly naming and confining components role within a single service. Our scheduler was generic enough to operate on its own, but it's role within our architecture was pretty confined. It's main optimization compared to other software like it was the inbound communication and authentication flows that made it easy to securely plug into.
- Lack of organization and vision at the service registry level. The scheduler didn't need a vastly different name, because it's purpose didn't really change. It did one thing and it did that one thing exceedingly well. There was a hole in the wider service registry that it could fill. As a result it was elevated to its own program in the service registry with its own deployment schedule.