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.
Migrate to a Vertical Slice Architecture from a monolith? Is it more like microservices? Does it replace Clean Architecture? None of the above. It’s about being driven by cohesion of business capabilities and business processes. It has nothing to do with layers or physical deployment concerns.
YouTube
Check out my YouTube channel, where I post all kinds of content accompanying my posts, including this video showing everything in this post.
Vertical Slice Architecture
Vertical Slice Architecture has everything to do with business capabilities and nothing to do with a monolith, microservices, clean architecture, or hexagonal imports and adapters. It’s all about defining the “what” of an organization’s ability to execute successfully some type of business activity. So, what exactly is a business capability? Most people intuitively know this. It’s essentially answering the question, “What would you say you do here?”
The problem arises when we focus solely on the technical concerns of what we’re trying to achieve. Vertical Slice Architecture aims to slice out capabilities, not just technical functionality.
The problem with this diagram, which is often misunderstood, is that it focuses on the technical concerns. However, the true point is that we’re trying to take out a slice of capability.
That’s not to say we ignore technical aspects; this could be a monolith or microservices, but that’s not the core of the discussion. We want to extract a slice of capabilities.
Entity Driven = High Coupling
To start exploring business capabilities, we should dig deeper. For instance, if we think about the transportation domain, we can identify various areas such as HR, finance, and accounting. Let’s take HR and look a little deeper. Within HR, we find capabilities like compensation and benefits, recruitment and hiring, and education and training. If we focus on recruitment and hiring, we can drill down further into processes like screening, evaluation, and interviewing.
This brings us to the idea of business processes, which are integral to these capabilities. I’ve been using the term “process” because that’s what business capabilities are about. They’re not merely entities; systems that are driven by nouns and entities often become brittle and hard to change due to high coupling.
Take, for instance, a “user service” that manages everything related to a user in the system. This service may handle login, employee management, and more, leading to a tightly coupled system. If any part of the user service changes, it could potentially break other services that depend on it.
The key takeaway here is that we don’t need one model to rule them all. We don’t need a single concept, like a “user”, to exist in just one place. There can be different vertical slices within the system that relate to a user but focus on different concerns.
Process
Consider a simple example: ordering a product online and getting it shipped to your house. This process involves numerous business capabilities and workflows. Initially, you have the act of ordering, but then you must consider how the product is dispatched, picked up, and delivered.
When the truck arrives at the warehouse to pick up the product, we need to think about what happens in the system. Do we just update a record to indicate that the item has been picked up? No, it’s more complex than that. We need to track multiple aspects like the shipment ID, the bill of lading, and various other workflow details. If we only expose CRUD operations, we miss out on the capabilities and workflows involved.
In vertical slices, we focus on business capabilities. For example, executing a shipment involves a series of actions grouped together that define the business process. Arrive at the Shipper, Pick up the freight, Depart, Arrive at the Consignee, and Unload the freight. This is why comparing vertical slices to monoliths or microservices doesn’t make sense. We’re prioritizing grouping by capability, allowing us to decide how to implement each vertical slice.
Models
One of the benefits of this approach is flexibility. Depending on the vertical slice, we might expose an HTTP API with underlying data or implement a rich domain model. Vertical slices enable us to think logically about our systems, allowing for various implementations, whether they are mobile apps or other services. It’s not entirely about the physical aspect of how they are deployed or written but logically how they are grouped.
Challenges
However, it’s important to note that vertical slices don’t magically solve all complexities in our systems. There will still be coupling between vertical slices, and how we manage that coupling is an entirely different conversation.
One significant hurdle is managing the inevitable coupling between different slices. Even though each slice is designed to operate independently, there can still be interactions between them. For example, the order processing slice might need to communicate with the shipping slice to update the order status. This inter-slice communication can introduce complexities that need to be carefully managed.
Another challenge is ensuring that the overall system architecture remains coherent. As more vertical slices are added, maintaining a clear understanding of how these slices interact becomes increasingly difficult. Without proper oversight, there is a risk of creating a fragmented system where different slices evolve in isolation, leading to inconsistencies and confusion.
To mitigate these challenges, it’s common to use an event-driven architecture to help decouple interactions, allowing slices to communicate asynchronously without creating tight dependencies, however coupling will always exist.
Vertical Slice Architecture represents an approach to software design, prioritizing business capabilities over technical constructs. By grouping functionalities around cohesive business processes, organizations can create systems that are more adaptable and aligned with real-world operations.
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.