it:ad:patterns:namespace_as_problem_boundary_strategy

IT:AD:Patterns:Namespace As Problem Boundary Strategy

Summary

It's true that Namespaces are for grouping common code together – but that's not the entire picture.

Namespaces are 'problem boundaries'.

Understanding only the first part – the grouping part – without the second part – the problem boundary part – leads to incorrect usage of namespaces, such as the creating of code folders for namespaces, in which to keep Enums grouped together, or Interfaces.

Take Enums as an example: they are just custom types to describe Domain Entities. You can't pass around a reference to an Entity Type without passing around the Enum along with it.

In other words, they go hand in hand with each other, and therefore are in the same problem domain, and hence, namespace.

Just because it's maybe easier to keep things organized by keeping Enums in a sub directory doesn't mean they get their own namespace (eg: App.Domain.Entities.Enums would be wrong – you wouldn't make an App.Domain.Entities.Int32 or App.Domain.Entities.Strings namespace either).

//This is wrong:
Corp/
       App/
             Domain/
                        UserEntity.cs
                        Enums/
                                  UserType.cs

The same goes for Interfaces. They aren't 'something different' that gets their own namespace –they are the Service itself…and go in the same namespace.

For organisational purposed, if you don't like everything getting lumped in the same folder, I totally agree. Use a sub folder for your enums, and interfaces.

Just note that having a sub folder doesn't mean it need be a sub namespace. That's a Java concept. Not a a C# rule. The IDE will hint it strongly, but that's just a style concept for the masses (IT:AD:Patterns:MS Sells VS (not Good Practices) Strategy).

  • /home/skysigal/public_html/data/pages/it/ad/patterns/namespace_as_problem_boundary_strategy.txt
  • Last modified: 2023/11/04 03:29
  • by 127.0.0.1