Whose name is in the namespace?

  • Article

There's more than one way to group your code.  Namespaces provide a mechanism for grouping code in a heirarchical tree, but there is precious little discussion about the taxonomy that designers and architects should use when creating namespaces.  This post is my attempt to describe a good starting place for namespace standards.

We have a tool: namespaces.  How do we make sure that we are using it well?

First off: who benefits from a good grouping in the namespace?  I would posit that a good namespace taxonomy benefits the developers, testers, architects, and support teams who need to work with the code.  We see this in the Microsoft .Net Framework, where components that share an underlying commonality of purpose or implementation will fall into the taxonomy in logical places. 

However, most IT developers aren't creating reusable frameworks.  Most developers of custom business solutions are developing systems that are composed of various components, and which use the common shared code of the .Net Framework and any additional frameworks that may be adopted by the team.  So, the naming standard of the framework doesn't really apply to the IT solutions developer. 

To start with, your namespace should start with the name of your company.  This allows you to easily differentiate between code that is clearly outside your control (like the .Net framework code or third-party controls) and code that you stand a chance of getting access to.  So, starting the namespace with "Fabrikam" makes sense for the employees within Fabrikam that are developing code.  OK... easy enough.  Now what?

I would say that the conundrum starts here.  Developers within a company do not often ask "what namespaces have already been used" in order to create a new one.  So, how does the developer decide what namespace to create for their project without know what other namespaces exist?  This is a problem within Microsoft IT just as it is in many organizations.  There are different ways to approach this.

One approach would be to put the name of the team that creates the code.  So, if Fabrikam's finance group has a small programming team creating a project called 'Motor', then they may start their namespace with: Fabrikam.Finance.Motor.   On the plus side, the namespace is unique, because there is only one 'Motor' project within the Finance team.  On the down side, the name is meaningless.  It provides no useful information.

A related approach is simply to put the name of the project, no matter how creatively or obscurely that project was named.  Two examples: Fabrikam.Explan or even less instructive: Fabrikam.CKMS.   This is most often used by teams who have the (usually incorrect) belief that the code they are developing is appropriate for everyone in the enterprise, even though the requirements are coming from a specific business unit.  If this includes you, you may want to consider that the requirements you get will define the code you produce, and that despite your best efforts, the requirements are going to ALWAYS reflect the viewpoint of the person who gives them to you.  Unless you have a committee that reflects the entire company providing requirements, your code does not reflect the needs of the entire company.  Admit it.

I reject both of these approaches.  

Both of these approaches reflect the fact that the development team creates the namespace, when they are not the chief beneficiary.  First off, the namespace becomes part of the background quickly when developing an application.  Assuming the assembly was named correctly or the root namespace was specified, the namespace becomes automatic when a class is created using Visual Studio (and I would assume similar functionality for other professional IDE tools).  Since folders introduced to a project create child levels within the namespace, it is fairly simple for the original development team to ignore the root namespace and simply look at the children.  The root namespace is simply background noise, to be ignored.

I repeat: the root namespace is not useful or even important for the original developers.  Who, then, can benefit from a well named root namespace?

The enterprise.  Specifically, developers in other groups or other parts of the company that would like to leverage, modify or reuse code.  The taxonomy of the namespace could be very helpful for them when they attempt to find and identify functional code that implements the rules for a specific business process.  Include the support team that knows of the need to modify a function, and needs to find out where that function is implemented.

So, I suggest that it is more wise to adopt an enterprise naming standard for the namespaces in your code in such a way that individual developers can easily figure out what namespace to use, and developers in other divisions would find it useful for locating code by the functional area.

I come back to my original question: whose name is in the namespace?  In my opinion, the 'functional' decomposition of a business process starts with the specific people in the business that own the process.  Therefore, instead of putting the name of the developer (or her team or her project) into the namespace, it would make far more sense to put the name of the business group that owns the process.  Even better, if your company has an ERP system or a process engineering team that had named the fundamental business processes, use the names of the processes themselves, and not the name of the authoring team.

Let's look again at our fictional finance group creating an application they call 'Motor.' Instead of the name of the team or the name of the project, let's look to what the application does.  For our example, this application is used to create transactions in the accounts receivable system to represent orders booked and shipped from the online web site.  The fundamental business process is the recognition of revenue. 

In this case, it would make far more sense for the root namespace to be: Fabrikam.Finance.Recognition (or, if there may be more than one system for recognizing revenue, add another level to denote the source of the recognition transactions: Fabrikam.Finance.Recognition.Web)

So a template that you can use to create a common namespace standard would be:

CompanyName.ProcessArea.Process.Point

Where

  • CompanyName is the name of your company (or division if you are part of a very large company),
  • ProcessArea is the highest level group of processes within your company.  Think Manufacturing, Sales, Marketing, CustomerService, Management, etc.
  • Process is the name of the basic business process being performed.  Use a name that makes sense to the business.
  • Point could be the name of the step in the process, or the source of the data, or the customer of the interaction.  Avoid project names.  Definitely avoid the name of the group that is writing the code.

In IT, we create software for the business.  It is high time we take the stand that putting our own team name into the software is a lost opportunity at best, and narcissistic at worst.