Out with the Onion, in with Vertical Slices

Vertical Slice Architecture is slowly becoming all the rage when given the opportunity for a new project or the chance for major refactoring of technical debt in legacy systems. So what are vertical slices? Why should you move away from the commonplace Onion Architecture? What are the motivations for the need of this new style of architecture? We’ll answer these questions and more as we explore Vertical Slice Architecture.

What are Vertical Slices?

The term “vertical slice” refers to a cross-sectional slice through the layers that form the structure of the software code base.
- Wikipedia Vertical Slice Page

This simply means that there exists a vertical slice of our application that runs from the user interface down to the deepest layer in our application such as the data access layer. These vertical slices exist for each command and/or query that exists within an application.

An example application that implements vertical slices could be an e-commerce web application built with .NET MVC and React. In this imaginary web application, we have a bit of functionality where a user can add a product to a favorite’s list. A vertical slice exists for this functionality where it would run from the client side React code, where the user clicks a button to add the product, down to the database layer, where the product is added to a favorite product’s table in the database.

Figure 1. High level view of vertical slice architecture.

Okay, that’s great and all, but why?

• The code for each vertical slice (or feature) lives within its own namespace (or feature folder).
• Less of a need to develop abstractions as the code for each vertical slice is very specific and so there’s not much of a need to develop services, repositories, factories, etc within a vertical slice.
• By isolating our vertical slices, each slice can take the optimal approach to accomplishing the request. For example, if the request deals with data access, our vertical slice could do so by using an ORM while another vertical slice uses a different method such as using a stored procedure.
• Context switching becomes less of a problem as everything related to that feature is in the current namespace. There’s no need to follow code down a rabbit hole across the application.
• Change requests from users or the business tend to be vertical in manor, so it makes sense to architect our application vertically as well. It is not often that you get a change request for something that is horizontal in nature.

Things to look out for

• Vertical slices should be isolated. One vertical slice should not reach outside of it’s namespace and it should definitely not call into another vertical slice.
• Code duplication is very likely as it is very possible that one vertical slice will have the need for the same business logic as another vertical slice. This can be fixed by pushing this business logic into a domain object or extension method.

How About an Example?

I know if you’re like me, then you like visuals and examples. Let’s take a look at an example of a folder structure for some vertical slices.

- Features
  - Products
    - AddFavoriteProduct
      - AddFavoriteProductController
      - AddFavoriteProductCommand
      - AddFavoriteProductResponse
      - AddFavoriteProductCommandHandler
      - AddFavoriteProductContainer.js
      - AddFavoriteProduct.js
      - AddFavoriteProduct.css
    - GetProductList
      - GetProductListController
      - GetProductListQuery
      - GetProductListResponse
      - GetProductListCommandHandler
      - GetProductListContainer.js
      - GetProductList.js
      - GetProductList.css

This visual really makes it all come together, right? You can really see the benefits that you’ll be gaining by keeping all code related to a feature in close proximity.

Are we really not going to talk about the fact that there’s front-end code mixed in with the back-end code?

I know, I know. That was my first reaction, too, when I first saw vertical slices spanning through to and including the UI (my initial introduction to vertical slices was limited to server-side code). If you think about it for a second, though, it does make sense. By including the front-end code in the same folder as the back-end code relevant to that feature, we gain all the benefits mentioned above, but most importantly the benefit of file proximity. This is especially beneficial if your development team is not split between front-end and back-end developers.

Wait! My development team is split between front-end and back-end developers

This is not a hard and fast rule that you must keep all code, both front-end and back-end, together in this same folder. If it makes more sense to make a split at the front-end and back-end, where the back-end code implements vertical slices, but giving front-end developers the freedom to implement features by pages or develop vertical slices of their own, or some other strategy, that is okay!

Let’s Wrap It Up

We’ve talked about what exactly vertical slices are and how they fit into application development. We also mentioned benefits for implementing this style of architecture such as close file proximity and choosing the best approach to do a particular job. I highly recommend you give vertical slice architecture a shot on your next greenfield application, or try it out as a proof of concept for the system that you are maintaining today.