Hacker News Reader

Comment by stevebmark | Hacker News Reader

AirBnB doesn't allow you to name microservices descriptively. It makes sense because it doesn't scale. After the 10th "SMS Service" is created, no one knows what any of them do. And that's kind of the point of microservices, you have lots of them. It's inevitable there will be overlapping functionality.

There's plenty of other reasons too.

Silly names are fine, it takes just as much time to learn what "Ernest" does as it takes to learn what "shipping" does. For both services, there's 30 seconds of learning, and then everyone knows what both names mean.

The anti-silly-service name dogma is misguided.

View on HN

After the 10th sms service I'd be curious to know why people have done the same thing ten times. If there is a real difference in functionality between those ten services, I suppose the next question is why don't their names reflect that?

One of the useful things about descriptive names is that it can help you detect duplicate work.

Ok, all of these services have different names, what do they do?

- Text Service

- SMS Service

- TwilioProxy

- Telephony Service

First, the same problem applies to service names like "Galactus" or "Buttforce". Second, a descriptive name is not the same thing as a service description. A descriptive name or label is as much a mnemonic device as is is a name. They're intended to be easier to remember, not to replace proper documentation. Third, just from the names it looks like Text Service is the front end for an ecosystem of texting related services, reach of which is implemented using a different technology. Though twilio and telephony look like especially bad names for services behind a texting service.

> After the 10th "SMS Service" is created, no one knows what any of them do

Yeah, that's always been my concern. "Descriptive" is a very precarious strategy because it takes very little to go from maybe descriptive to generic and confusing. Multiple variations of the same "descriptive" name are another common issue. I see often a lot of very similar named services that are the bane of naming in my opinion. Someone made a User Management Layer and then someone else made a Person Data Service and next thing you know you see a User Data Service and now it's just confusing. Factor in that each one of those things gets called the UML, PDS, and UDS and it just gets worse (did I mention they each connect to the Person/User Data Store/base).

> it takes just as much time to learn what "Ernest" does as it takes to learn what "shipping" does.

If that is right we should apply it everywhere, as it does not matter. My method many is going to be PeterPan and the class name Wonderland. It's as easy to learn as a descriptive name.

> After the 10th "SMS Service" is created

Are you also going to create 10 classes with incompatible but overlapping interfaces and tradeoffs?

Some names are descriptive and other are just names. Your coworker is more likely to be named Ernest than GuyWithLongHairThatListenToPopMusicWhileReadingMangaAtTheParkAndIsReallyGoodWithPython and that is probably a good thing.

And there are five Ernest and twelve Daniel, maybe we should name most classes the same also. When compiling the code a prompt may ask what Ernest do you mean.

I don't think that proponents of "use silly names" actually mean "use the same name over and over"

com.company.shopping.user.experience.shipping.intake

What's the problem? /s

Reply on news.ycombinator.com