Should namespaces within a single project act as boundaries?

Question

When working within a single project that contains multiple namespaces, should these namespaces be treated as boundaries? Or is it acceptable that any namespace can access any other namespace?

For example, say I have the following namespaces in a project called Physics

• Physics.Models
• Physics.Math

Say in this case that some Models use classes defined in Math, and Math uses classes defined in Models. Is this an acceptable solution? Does there need to be some hierarchy to the namespace names that indicates dependencies? Something like

• Physics.Math
• Physics.Math.Models

Are there rules that should be followed? Or is this just left up to the developer to make smart and pragmatic decisions about relationships within a single project?

Answer 1

The short answer is that no there are no rules and its up to the developer as shows by the fact that the language itself doesnt care how you go about dealing with namespaces.

That being said, the way that you split up your namespaces, if you use them at all, falls down to the way the rest of your project is divided and what you(and your team) decide is the best way to address it. For your example, I would personally go with your first approach becasue it better communicates the use of the items in the namespace, but that is to me and may well not be the way someone else sees the namespace nomenclature.

tl;dr No, the language doesn't care, and it's a stylistic choice you'll have to make yourself