Names MUST NOT contain offensive terms

Avoid offensive words like "blacklist", "master", and "slave". Avoid violent names like "kill", "killer", and "war". Also avoid political terms like "brexit" and "putin". Avoid names which can sound offensive for your colleagues, e.g. "Den Den Mushi" are fictional snails, but "Mushi" sounds a lot like "Muschi" (pussy) in German. Other terminology can also be problematic. For example, imagine you work in a telecommunication company and name one of your services "big brother" — guess what happens if this name is leaked to the press?

Names MUST NOT include organization/team identifiers

Applications typically outlive their organization structure. Adding department/team identifiers to your application names will cause confusion and unnecessary renaming. This is especially problematic if your org/team names are codenames. For example, team "kingpins" has created an application "kingpins-user-frontend", what happens if the application is handed over to team "gravity"?

Microservices should be owned by exactly one engineering team, but they should not reflect the team's identity.

Names SHOULD describe the application's purpose

The application's name should describe its business purpose, i.e. why it exists in the first place. The application's purpose should not change, otherwise we need to introduce a new application with a different name. A microservice should have one responsibility. This should be reflected in its name.

Don't assume that others will have the same context as you and understand the name's meaning. Make sure to ask colleagues who are not familiar with your business domain to review your names.

Names SHOULD NOT consist solely of acronyms

Acronyms are sometimes a necessary evil, but avoid acronyms unless they are well established in your company. "CMS" (Content Management System) is a well established acronym. CLOTS, BUGR, and NIPL are probably not well-known. Avoid cryptic acronyms.

Names SHOULD NOT use broad/general names for local purposes

Large organizations tend to use similar entities in different domains, e.g. there is probably more than one "item", "order", and "user" entity in your company. Avoid using too general names like "item processor" or "user service" unless you are absolutely sure that your organization only has exactly one definition for "item" and "user".

Names SHOULD NOT be clever or rely on temporary concepts

I wholeheartedly agree with Austerity as a naming principle:

It can be tempting to use a bit of humor or a cultural reference in code to lighten the mood a bit, but doing this can violate many principles. For example, a joke name can reduce understandability of the underlying concept and reduce the name’s consistency and searchability. Colloquialisms (which are only understandable to certain audiences) and puns can cause similar issues. They may seem fun initially, but after dealing with them for years, that fun will turn into apathy and (more likely!) antipathy. When in doubt, choose names that are literal and dry.

Names CAN represent a product branding

Internal application names should not be cryptic codenames, but establishing a brand sometimes makes sense. Don't introduce a codename unless you are willing to invest into establishing a (product) brand, e.g. a well-recognized codename within the company or for promoting an Open Source project. Spotify released their developer portal "Backstage" which is now a recognized OSS project. Zalando has well-established codenames for central infrastructure components like Nakadi and Skipper. Almost every Zalando engineer knows what Nakadi and Skipper are.

Your local "raccoon" and "wingman" microservices don't need branding, their codenames just lead to confusion.