[carlosrdrz]

Surely there is some middle ground? Why everything has to be black or white and everyone needs to give silver bullet rules?

A service that stores something can be called "catalog" and it is descriptive, short and memorable. On the other hand, a service that does too many things can be called "zeus" or "cyclops" or whatever and that's okay too. It's difficult to have memorable and short names when things do too many things, or as mentioned in the post, they might change responsibilities.

Also, when you have something descriptive composed of multiple words (like "data-streaming-analyzer") people will certainly start using acronyms (DSA) and then you're back to short names than don't mean anything.

There's a world where everything is not called "pikachu", "cyclops", "potter" and "tortilla", nor "main-store-red-website", "download-analytics-store-and-processing", "sells-stream-processor". Use both. They are both useful!

[ryanjshaw]

I feel it's helpful to distinguish between "applications" and the "services" that make up those applications.

- application name: not descriptive unless you are 100% sure scope will not change over time (e.g. a specific report mandated by a regulator); exception to the rule: I actually like using initialisms because they start off descriptive but then over time people use the initialisms exclusively and its almost like you invented a non-descriptive word without the initial confusion

- service names: start with a monolith that is just the application name (or suffix "Core"), only split into other services once you have a good reason, and scope is clear, and then give it a descriptive name