Company namespace in web applications

Question

Most (good) namespace conventions require a company name scoped namespace.

eg

CompanyName.ComponentName.x.y.z

How well does this translate over to web applications? In many websites, the company is referred to by the website name (eg, Facebook, MySpace). Does this convolute namespaces, making them appear as if they can only apply to a single project?

For example, let's pretend a company creates WebsiteA(.com), and is henceforth referred to as 'WebsiteA'. WebsiteA creates a reusable authentication component for their project. They namespace it as such:

WebsiteA.Auth.x.y.z

A year later, WebsiteA creates a new website, WebsiteB, and decide to use their previously created WebsiteA.Auth component.

Does this obscure the namespace? Should the company have used an alias separate from their website name as their CompanyName in their namespacing? Afterall, WebsiteA.Auth isn't coupled directly to WebsiteA.com, and WebsiteA is now more of a project of the company, rather than the entire company.

Answer 1

What is the difference you make here between web applications and "other" applications? Namespaces doesn't depend and doesn't have to depend on the type of the project, especially since the same library can be used by both web and non-web applications.

If the namespace contains the name of the website, actually, it's not the name of the website, but primarily the name of the project, or in many cases the codename of the project.

The final name of the product is often different from the original name of the project. In this case, it is not unusual to keep the old namespaces containing the codenames, whatever the final name is (in other cases, refactoring can be done, but may cost a lot of money). Of course, in the case when old namespaces remain, it is essential for the developers to know not only the name of the product, but also the codename of the project to understand the relation between the namespaces and the final products.

Answer 2

Most of the namespaces I have worked with have been more along these lines:

CompanyName.TechnicalDomain.AppName.FunctionalArea.Class

or, in the case you suggest where the code is intended to be shared:

CompanyName.TechnicalDomain.Common.FunctionalArea.Class
CompanyName.Common.FunctionalArea.Class

In the case of WebSiteB now using code from WebSiteA, it is a clear case where the code is a candidate to become common code. It might be worth deciding at that point to move the code to the appropriate .Common. namespace and then use .Common in WebsiteB. Eventually you should transition WebsiteA over to .Common. as well in future updates.

Answer 3

First of all, the namespace would not have been WebisteA.Auth.x.y.z (as WebsiteA is a website, as you said).

Facebook, MySpace, Twitter, etc. is a company and their product is called by the company name. Facebook, to give an example, created Cassandra, so you would have seen the project having com.Facebook.x.y.z namespace (I'm not comparing the Facebook Cassandra to the Apache Cassandra, which Facebook gave the project to).

I've seen only libraries in the following terms:

domainExtension.CompanyName.ProductName.x.y.z. I hope this answers your concern.