This is based on an email I send my .NET team at work
I’ve been thinking about trying feature folders on a future .NET MVC project to see how I like it. A feature folder architecture bundles the source code files together by business domain feature, instead of by what type of file it is.
So for example, in our Overnight Website Challenge project, we have a folder for Controllers, a folder for Views, and a folder full of Models. Pretty typical stuff, and it looks something like this:
If you’re new to the project and asked to update the Camp Signup feature, you have a lot of files to bounce around in and sort through. Imagine this were a bigger site with dozens of controllers and related views and models. It can get unweildly quickly.
The feature folder architecture structures those same files like this:
Now when you want to work on the CampSignup feature, every thing you need is right there and easily available.
Feature agnostic components like routing, logging, persistance can still be stored elsewhere where they can be reused.
If you’re interested in how to set this up so that MVC can find the views and models, this post has some samples for how to customize the view engine to know where to look.
Jimmy Bogard (author of AutoMapper) has been a big proponent of this solution architecture for a long time. Here’s a talk he gave on why he prefers to structure solutions around features rather than around layers. Pay attention to the diagram he has contrasting this structure with the more common tier structure.
Keep in mind, his experience is with enormous and complex sites that have hundreds of controllers. This approach is probably overkill for a small project.
If you want to see it in action, he has a sample on github: https://github.com/jbogard/ContosoUniversityCore