This article describes how namespaces and folders might be structured.
In this architecture the root namespace is the company name, for instance:
JJ
The 2nd level in the namespacing splits up into the following parts:
| JJ.Data | The Data layer including the entity models and storage of data. |
| JJ.Business | The Business logic: guarding the rules of the system. |
| JJ.Presentation | The Presentation layer: the visual part of a program. |
| JJ.Framework | Reusable code, independent from any functional domain. Any layer in the software architecture can have reusable code to support it. |
And second in line:
| JJ.Utilities | Small programs, e.g. health checks, loading stuff in a database. |
| JJ.Demos | Code for demo purposes or trying things out. |
The 3rd level in the namespacing would be the functional domain:
The ‘functional domain’ of the framework layer might be a technical aspect:
The 4th level in the namespacing denotes which technology is used. It is sort of analogous to a file extension. You might find two assemblies: one platform-independent and one platform-specific:
This means that the platform-independent part of the code is separate from the platform-specific part. This also means, that quite a portion of the code can be shared between platforms. That way we can choose which technologies we want to depend on.
The next level in the namespacing can be a design pattern. It would become a sub-folder inside an assembly:
For bigger projects, a design pattern folder may split up into sub-folders for main entities or partial domains:
Assemblies with automated tests can add the suffix Tests:
Putting the main layers (data, business, presentation) before the functional domain was a choice, that made sense at the time:
Not every software product had a data, business or presentation layer. Most products just had one of those layers.
There was a certain n-to-n relationship between products. A functional domain could be missing a layer, an app could use multiple functional domains, a single functional domain could have multiple front-ends.
It made more sense there, to make the main layer the first subdivision, and drop in the functional domains from there.
In other projects it might make more sense, put the functional domain 1st and the main layer 2nd.
Functional domain:
Main layer:
In this namespacing, the functional and technical concerns seem scrambled.
These are the functional concerns:
And these are technical concerns:
What happened here, is an attempt to organize things into bigger and smaller chunks.
The split up per company may be the largest concern, while a 2nd concern is the split up into main layer (data, business, presentation).
A functional domain (Calendar, Ordering) was considered a larger concern than the specific technology used (e.g. NHibernate, MVC).
And a design pattern may be a level of detail below that.
What’s also done here is putting the assembly subdivision first, and the folder subdivision after that.
This would be the assembly:
And this would be the folders in it:
We could keep functionality together, and technical things together:
Functional things:
Technical things:
Just looking at this, it does make a lot of sense.
But this might get in the way of our plans to put the assembly 1st and the folder 2nd.
C:\Repositories
|
|- JJ.TheProject
|
|- JJ.TheProject.sln
|
|- Data
|
|- JJ.TheProject.Data.csproj
|
|- Entities
|- Mappings
|- Helpers
Project file:
JJ.TheProject.Data.csproj
Root namespace:
JJ.TheProject.Data
Sub-namespaces:
JJ.TheProject.Data.Entities
JJ.TheProject.Data.Mappings
JJ.TheProject.Data.Helpers
Assembly name:
Company.SoftwareLayer.FunctionalDomain [.Technology] [.Tests]
Sub-folders for design patterns:
Company.SoftwareLayer.FunctionalDomain [.Technology] [.Tests]
[.DesignPattern]
Smaller projects, single sub-folder Helpers instead:
Company.SoftwareLayer.FunctionalDomain [.Technology] [.Tests]
[.Helpers]
Bigger projects’ design patterns split up into main entities or partial domains:
Company.SoftwareLayer.FunctionalDomain [.Technology] [.Tests]
[.DesignPattern] [.PartialDomain]