Sponsor: Do you build complex software systems? See how NServiceBus makes it easier to design, build, and manage software systems that use message queues to achieve loose coupling. Get started for free.
As with anything that gains traction from a wider community, some misconceptions develop and spread. Vertical slice architecture falls into that trap. Don’t worry. I’ve got you covered to demystify some common Vertical Slice Architecture myths and why they likely exist. Let’s set the record straight.
YouTube
Check out my YouTube channel, where I post all kinds of content accompanying my posts, including this video showing everything in this post.
Share Nothing
Easily, the biggest of the Vertical Slice Architecture myth is that you cannot share anything between features. That’s always the question I get in the comments. “How do I share cross-cutting concerns?” or “But I’ll end up duplicating logica all over the place!”
I think this misconception exists because of the belief that features should be entirely independent of other features. While that’s somewhat true is that if you’re focusing on capabilities, you’ll have some that have some features that have nothing to do with others. However, you will have features that relate to each other, which might require something shared.
An example of this is the underlying domain or data model related. Another example is related to workflow, where one feature will kick off another feature.
Also, sometimes, I find people think of features as too granular, which also can cause this confusion. A feature can be a combination of commands and queries, but it can be as small as an individual command or query (think of a report).
In the example above, you might have two features that share the same validation while all the features share the same underlying model. That could be a data model or more of a domain model.
There’s nothing wrong with this. Organizing by features focuses on your system’s capabilities (more on this later).
But the key point is that you don’t have a massive underlying model that spans the entire system. Instead, you have a model that’s focused and used specifically for the features that need it. What you share becomes very focused on the features.
One of the benefits of vertical slices is your ability to choose per feature it’s implementation details that may differ from other features. For example, you may choose to use a domain model with an aggregate when you implement a command, while you may choose to query the database directly for a query. Those two might use different libraries (dependencies) for each concern. That’s not to say they must, but it’s an option.
Little to no abstraction
I think this myth exists because people think of Vertical Slices as the opposite of Layers or as that it’s at odds with Clean or Onion Architecture. But that’s not the case.
The point of vertical slices is about cohesion. Clean (or Onion) Architecture is about the direction of dependencies and how you manage coupling. They are orthogonal concerns and not mutually exclusive.
For example, you can still have a data access layer or some abstraction over data access. The question is do you need that abstraction?
As an example, if you were using ORM and it had 100’s usages all over your application layer. If you want to change that ORM with some other form of data access, that might be a massive undertaking to change all those usages. This is because you’re highly coupled from your application layer to the ORM. If you hide the ORM behind some data access layer, it’s still the same problem. The problem is the high degree of coupling. Coupling here is the issue.
However, if you have a dozen usages for a set of related features that use that ORM, and you want to change it to something else or change the underlying database itself, that surely will be easier to manage that change for a dozen usages instead of 100s.
The point is that you’re segregating and deciding how you couple per feature rather than an entire layer.
This is why I think the misconception exists because once you start getting narrow in features, you start realizing the value of abstractions decreases because you have less coupling to certain dependencies.
Low barrier to entry
Vertical Slice Architecture is easier than something like Clean Architecture. I disagree with this because as I already mentioned, they aren’t mutually exclusive. It’s about fundamentally understanding coupling and cohesion and the trade-offs you have to make.
Your systems architecture is comprised of various architectural patterns, such as vertical slices, layered, event-driven, etc.
Ultimately, it’s understanding what the problems are and applying various patterns that help solve those specific problems. Understanding the trade-offs you are making in doing so, often around coupling and cohesion.
On the surface, it might seem easier to understand Vertical Slices, however, because you can make decisions and have more options per slice, but that comes with the trade-offs, such as having inconsistent ways of implementing features. It’s a double-edged sword.
It’s not easier to understand because you can screw up anything you don’t truly understand.
Features don’t impact other features
This is another really popular Verital Slice Architecture myth. This myth goes back to the misconception of sharing nothing. You’re going to have some coupling between features. Often times, this is because of business processes or workflows where one feature ends, and that’s the starting point for another. Your workflows, while different vertical slices still have some degree of coupling, it just depends on how.
I do agree that you’re less likely to impact other features that are unrelated because you don’t end up sharing various cross-cutting concerns over all your features. As mentioned earlier in my ORM example, because your limiting coupling to specific features to that dependency, it’s just those features can be affected if you make a change. Meaning if have one massive data access layer that’s coupled to everything, everywhere, and you make a change to that data access layer, you’re going to affect all kinds of usages. But as mentioned, since your features decide themselves and limit the coupling to shared concerns, you’re limiting the impact of change.
Requires Messaging for decoupling
And to piggy back on the last misconception, you’re going to have coupling between features, especially workflows. But that doesn’t mean you need messaging or have to be using an event-driven architecture.
This misconception exists because using the publish-subscribe pattern and an event-driven architecture is a great way to remove temporal coupling. You sill have coupling, but you just removed the temporal aspect.
A lot of the illustrations of vertical slices will show the usage of messaging or an event-driven architecture of this reason. But that doesn’t mean vertical slices architecture requires it.
Your architecture is composed of all kinds of different architectural patterns. If you need to remove temporal coupling and want to loosely couple between features or groups of of features, than event-driven architecture can be a solution to that problem. But Vertical Slices do not require it. You could still have one feature make an in-memory call via some abstraction another feature exposes. It depends if that’s appropriate for your use case.
CRUD isn’t use-case driven
This isn’t a myth; I just wanted to add it because I think it’s the reverse. Vertical slice architecture is about focusing on your use cases. CRUD is the exact opposite of that. CRUD doesn’t capture intent. When you organize code around features, you’re explicitly capturing your system’s capabilities.
If you’re simply doing Create-Read-Update-Delete and generating an API and UI around a database, do you really need Vertical Slices? Not really. The value to me is capturing the capabilities, workflows, and business processes.
Join CodeOpinon!
Developer-level members of my Patreon or YouTube channel get access to a private Discord server to chat with other developers about Software Architecture and Design and access to source code for any working demo application I post on my blog or YouTube. Check out my Patreon or YouTube Membership for more info.