Exploring Software Architecture: Vertical Slice
A perhaps less common architecture, when compared with the likes of Clean, Onion or Hexagonal, is the Vertical Slice Architecture (sometimes known as VSA). In this article I’ll describe what it is, when and why you’d want to consider it and some of the pro’s and con’s to consider when looking at choosing this architecture, based around the commercial experience I’ve had whilst using it.
Lets dive in.
What is the Vertical Slice Architecture?
Jimmy Bogard (creator of MediatR) defines VSA as the following within his article that he wrote back in 2018:
So what is a “Vertical Slice Architecture”? In this style, my architecture is built around distinct requests, encapsulating and grouping all concerns from front-end to back. You take a normal “n-tier” or hexagonal/whatever architecture and remove the gates and barriers across those layers, and couple along the axis of change…
In essence, VSA is an architectural approach which aims to encapsulate all logic that relates to a single “feature” or “request” within its own “slice” in isolation; cutting across all the necessary horizontal layers (presentation, application, domain, data access etc) of what could be a N-Tier architecture in order to carry out its duty.
Note: for more info on N-Tier, check out this article.
So if we attempt to illustrate what a traditional N-Tier architecture looks like:
We have areas of responsibilities stacked one upon the other. Based upon Jimmy’s definition, Vertical Slice can be illustrated as:
Where “Slice” is a “request” or “feature” which is encapsulated within its own vertical and, if it has to, cuts directly across each horizontal layer in isolation of other slices. What this provides is both high coupling of dependencies within a given slice, but also high cohesion of those dependencies per slice.
Note: Jimmy also has an awesome talk which he gave at NDC where he dives into more detail on VSA which is worth checking out and can be found here.
Why opt for Vertical Slice?
“But wait, aren't you supposed to aim for loose coupling and high cohesion in software development?” I hear you ask! Yes, and this is perhaps what separates VSA from traditional layered architectures, and perhaps adds some confusion (and naturally, debate), as coupling within a slice should be high but between slices should be low. As Jimmy states, we should aim to:
Minimize coupling between slices, and maximize coupling in a slice
The main benefit this provides is that each slice then becomes the “master of its own destiny” in regards to carrying out its responsibilities. In theory, this ultimately provides a development team (or many) the capability to introduce change independently and safely regardless of what currently exists (or doesn’t). Or as Jimmy puts it:
“New features only add code, you’re not changing shared code and worrying about side effects. Very liberating!”
And having worked with it commercially on a couple of projects, it can be very liberating indeed!
What would this look like in practice?
Lets attempt to illustrate by building upon the default dotnet webapi project using weather forecasts and minimal api’s. We’ll take this template and walk-through re-arranging it to follow the principles of VSA, as well as add a new “slice” if functionality to it.
If you want to jump straight to an example repository, you can find one here.
Possible Folder Structure
Using the WebApi template, out the box you will be presented with the following structure:
With our working weather forecast project, lets begin to look at a way in which we could create a screaming VSA folder structure and refactor the existing endpoint within program, into a slice of its own.
First we’ll add a Features directory to hold our features (or slices) and add our first slice to get a forecast:
Here, the GetForecast.cs slice contains all necessary components required in order to fulfil retrieving weather forecasts. We define the request, the handler to handle the request, the response in which to return, the endpoint to expose and finally the weather forecast model. If we want to modify any part of this slice, then everything we would ever be looking for will be right within this folder.
Lets now add another slice to search for forecasts that have a temperature greater than or equal to what the user has defined:
Similar to before, we create the request (as we are now taking in user defined query filters as part of the request), the query to execute within our application, the response to provide, the request handler as well as the endpoint which exposes the functionality.
Going back to Jimmy Bogard’s description of VSA, we could illustrate the slices defined above as the following:
One of the main benefits of each slice being loosely coupled to its peers, is that each can define how they wish to carry out their duties. If we looked at the theoretical implementations of our above slices, we could imagine them being something like the following:
Where perhaps our get forecast slice defines a SQL query to run against a relational data store, and our search forecast slice looks towards a search engine to retrieve forecasts.
Pros, Cons and Considerations
As with almost all software architecture decisions, its about managing the trade offs you make in order to deliver business value. Based on my own experience, I'll attempt to highlight a few below.
Pros
Creation of slices in isolation
Being able to create a new slice of functionality in isolation from others can really help scale a development teams output by being able to parallelise feature development
Safe modification of logic within a slice
As each slice is isolated from its peers, the risk of introducing a defect or a breaking change to another slice is next to none.
New code only added for new slices
When a feature is complete, then any new feature will require its own code.
Cons
Potential duplication across slices
As the application and feature list grows, if refactoring is not continually applied along with the growth, then duplication of identical code can become an issue.
Architecture learning curve
If teams have not applied this style of architecture before, and the architecture itself is loosely governed, then it can take time to understand and apply correctly.
Harder to standardize patterns and approach's
Given each slice solves its own problem, it can be challenging to standardize the anatomy of a slice and what should standards and patterns shouldn’t be used during its construction.
Further Reading
I’ve mentioned Jimmy Bogard’s article and NDC talk on VSA but shall link here too in case they have been missed. These are both worth a read and a watch.
Milan Jovanovic has another great article on VSA here as well as a host of YouTube videos on his channel covering the topic and diving deeper into how you can begin to apply DDD to your VSA applications.
