BDD – Files/Folders/Namespaces (BDD)

Files/Folders
One thing that can be troublesome when moving to a BDD style approach is how to organize your files and folders, so far I’ve tried two approaches:

1. One class in each file – So if you have When_associating_an_order_with_a_customer and When_associating_an_order_with_a_preferred_customer then they’d be in seperate files even though they are very closely related. If they share a base class, or a class they both compose, then that would be in yet another class (presumably).
2. Multiple classes per file – As an example you might group the Order addition contexts into a file called OrderPlacementSpecifications, the file could also contain the shared base class (if you went down that road).

To me the second approach has a couple of advantages:

1. Gives the reader extra information – By grouping the two order placement classes we tell the reader that they are quite closely related.
2. Simplifies folder structure – If we go for the other approach, one class in each file, then we’re probably going to have to have more folders. The addition of the extra files and folders definitely makes the solution file harder to structure.

To give you an idea here’s a screen shot of a part of the folder structure for a sample app we’re doing:

Namespaces

In addition to files/folders I’ve tried a few approaches to structuring namespaces but the approach I’m trying now groups related artifacts. For example:

1. Specifications.Users.Domain
2. Specifications.Users.Domain.Contacts
3. Specifications.Users.Services
4. Specifications.Users.Domain.Repositories
5. Specifications.Users.UI.Controllers

The “Specifications” bit adds very little but I think grouping all specifications related to users is useful, not least as R# makes it easy to run all the specifications in a namespace. This can be useful if you have a big solution and only want to run the specifications for the area your working on. Its also worth saying that its “Users” to avoid clashing with the “User” class.

Folder wise however we’re using a standard approach where your Repositories are in a completely seperate folder from your controllers, even though they might both relate to a particular entity. To me the lack of relationship between our folders and namespaces isn’t a problem though, with R# its easy to find a file/type and in addition the folder/namespace tell you two different things about your codebase (one by “layer”, one by “feature”).

So I’m interested in peoples views? I’m guessing you’ll all dislike it though because from what I’ve seen no matter what you do people will be unhappy with your file/folder/namespace scheme. Pluse we’ll probably turn against this approach next week….