Feature Grouping Code

There are many ways you can structure your application in terms of projects, however something I usually don’t discuss, but is quite handy, is grouping code via Feature, instead of Function. This method has been around for a long while, and I am not the first to use this, but I want to highlight this approach, since it is generally not shown in any of my code samples. I do use this approach, in all of my production projects, when I get a say in it.

Feature Grouping

Also known as Vertical Grouping, Feature Grouping, is grouping together code, that is related to the same feature. For example, if you have a number of pages tied to the authentication and login of a user, then another feature of your main app. It is convenient to group them as such.

You will find that you jump between ViewModel and View, quite often, and it is far easier to do this, when they are right next to each other in your Solution Explorer. For those that use a project setup that recommends having 2 separate projects for Views and Logic, I still group by feature, though I have the feature folder structure replicated across the Logic and View project.

Function Grouping

To show the other approach, that you may be more used to, is Function Grouping, also known as Horizontal Grouping. This is where you group together code based on Function, instead of Feature. For example, grouping your Views, View Models, and Models, together.

You can already see from such as small sample, how much easier Feature Grouping is to navigate, rather than Function Grouping.


I have completed many projects, using both approaches, and I can personally recommend that Feature Grouping your code, is easier to navigate, once your code base reaches even a small size. You don’t have to feature group everything, and what you group by feature, is up to you, to decide in your project.

However, you will want to switch to Function Grouping, when you get to classes that aren’t tied to a feature, but tied to a function. For example a Service or Repository. In this case, it may be easier to group those by Function.

I will make more of an attempt from now on, to show this approach in my future code samples.


  1. Nigel Sampson

    Why not both? 🙂

    For a project that’s big enough where a discussion about how it’s split up becomes an issue I tend so split both vertically and then horizontally.


    1. Adam Pedley

      I haven’t tried that before. I tend to like the feature grouping, even in larger projects, because if your naming is the same, then the View and ViewModel are straight after each other. Functional grouping removes that particular advantage.

      1. Nigel Sampson

        I think it depends on how big each feature is, for a non trivial feature I find the horizontal split makes it slightly easier to find things.

        I’ve also seen it done the other way


        But that approach doesn’t appeal to me.

        Having said that, how often do we browse the solution explorer versus just exploring for types using VS / R# find?

        1. Geoffrey Huntley

          Doing it this way kinda defeats the purpose, which is to reduce the cognitive overhead of working with a codebase.


          re: How often do we browse the solution explorer versus just exploring for types?

          Every damn time a newbie joins the project (which we should be optimizing for) or a veteran works in an area they have never worked before.

  2. Michael Foden

    It’s definitely an interesting concept – I think I am going to try it for my next project and see how it goes.

  3. xleon

    I´ve always wanted to do this before and I didn´t because nobody was doing it. Good to see it´s working for you.