Imagine a “UserProfile” service. It’s accessed from everywhere to show the handle name, address, icon etc. of your user.
Your application grows and your users want way more customization, now they get personas and avatars and can show different profile to different people. Those are full of breaking changes that you want to isolate from the legacy “UserProfile”, how do you name your new service ?
Think of your new service as having a different deployment target, its own DB, and could be under a different repo altogether.
From your point on versioning, I'd assume you'd actually call it UserProfileV2 ?
PS: to get back to the original point, you're still stuck with a "UserProfileV2" service that does a lot more than just user profiles, but that's not reflected in the name.
> PS: to get back to the original point, you're still stuck with a "UserProfileV2" service that does a lot more than just user profiles, but that's not reflected in the name.
From what it said in the original comment, it still seems like a user profile to me.
Some of you are thinking, well, what if you need to interface with facebook dot com? Easy, I'd call it the SneedFeed. If you know you know.
Sound like it's better to make a new service. Isn't that the point of Single Responsibility concept?