Differences

This shows you the differences between two versions of the page.

Link to this comparison view

it:ad:patterns:namespace_as_problem_boundary_strategy [2019/03/24 12:02] (current)
Line 1: Line 1:
 +# IT:​AD:​Patterns:​Namespace As Problem Boundary Strategy #
 +
 +
 +
 +<callout type="​Navigation"​ class="​small">​
 +* [[../​|(UP)]]
 +{{indexmenu>​.#​2|nsort tsort}}
 +
 +
 +</​callout>​
 +
 +
 +<panel title="​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.
 +
 +
 +</​panel>​
 +
 +
 +### Enums ###
 +
 +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
 +
 +
 +
 +
 +### Interfaces ###
 +
 +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]]).