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.
Is Vertical Slice Architecture better than Clean Architecture or Ports and Adapters? You’ll hear a lot advocating for Vertical Slices and often, when doing so, trying to pin it against other types like clean, onion, ports and adapters. So which one is better?
YouTube
Check out my YouTube channel, where I post all kinds of content accompanying my posts, including this video showing everything in this post.
Clean Architecture
You might be familiar with this diagram illustrating Clean architecture. What’s defined in each ring is unimportant and there can be more or less of them. What’s important about it is the arrows illustrating the direction of dependencies. Ultimately this is about coupling (as is most in software design).
Our Entities and Enterprise/Domain Business Rules are defined at the very center. This is important because the direction of dependencies illustrates that our entities don’t depend on anything. This makes it stable because everything around it can change and won’t affect our Entities/Domain Business Rules.
Hexagonal Architecture / Ports & Adapters
Very similar is Hexagonal Architecture / Ports & Adapters. As you can see, the center is defined as Application Core. This is where your business rules will live. You can also see labels of Business Events, Notifications, Persistence, etc., which are interfaces and/or contracts that are our ports. What implements those interfaces or contracts are the adapters.
What’s common between Clean Architecture and Hexagonal Architecture / Ports & Adapters is the center, the core. That’s where our business logic lives because we don’t want it to depend on I/O or various application-level concerns.
You’ll always hear don’t mix database calls with business rules. This is exactly what both are trying to solve.
This is a typical illustration of the direction of dependencies with clean architecture. If you’re in the .NET space, the most common templates will have a project structure with this type of reference between projects.
I’ve mentioned it already, but our “Domain” project has no dependencies. It doesn’t reference any other projects. So, if another project makes some type of change, it won’t force us to change anything within our domain project. For example, if we change our underlying database or maybe our web framework, that doesn’t affect our domain. It’s stable.
We’re battling against coupling.
Coupling: the degree of interdependence between software modules
Vertical Slice Architecture
Vertical Slice Architecture doesn’t come at it from the same angle, although it has a similar effect. It’s not solely about coupling but rather cohesion.
The driver is cohesion.
If you take the above illustration of clean architecture, vertical slices take a slice of that out based on a feature or capability.
The cohesion of the capabilities of our system is driving us. We’re grouping functionality often based on workflow or business processes. How this affects coupling isn’t at a technical level but more of a logical boundary level.
So this means we might split up logical boundaries into vertical slices and, even within them, have vertical slices of features.
That’s not to say you don’t care about isolating your domain and business rules from I/O or application-level concerns. That’s why the comparison between vertical slices and others doesn’t make any sense.
The term “Architecture” alone doesn’t make sense. Your system’s architecture is a collection of architectural styles and patterns. For example, you could use Virtual Slices, Clean Architecture, and Event-Driven architecture. They aren’t mutually exclusive.
One of the benefits of vertical slices is the ability to define the technical details of each slice per slice.
In one slice, you might have a lot of complex business rules, and because of that, choose to use ports & adapters. In another slice, it could be very CRUD-driven and has only data validation, which you choose just to use data models and transaction scripts.
Coupling & Cohesion
Vertical Slice Architecture isn’t better than Clean Architecture, Hexagonal Architecture / Ports & Adapters, or any other architectural style. They have different concerns and focus.
Vertical Slices is about thinking about cohesion around capabilities and how you couple between those capabilities. It does not emphasize coupling at a technical level like Clean Architecture or Hexagonal Architecture / Ports & Adapters.
Prescription
I think many people go wrong when they use a project template as a prescription for organizing code.
This is a common project structure template in .NET. There’s nothing wrong with it. But does it make sense in every context to use Clean Architecture? I don’t think so. An example of this template is your typical to-do app. Does a CRUD-driven simplistic app need to worry about coupling, or are you adding more complexity through indirection? Maybe you do if you have a lot of complexity. But the problem is using any type of template as a prescription without understanding why it’s guiding you down a certain path. It’s solving problems you might not have.
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.