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.
How do you share code between vertical slices? Vertical slices are supposed to be share nothing, right? Wrong. It is not about share nothing. It is about sharing the right things and avoiding sharing the wrong things. That is really the point.
YouTube
Check out my YouTube channel, where I post all kinds of content on Software Architecture & Design, including this video showing everything in this post.
Boundaries
If you have watched my videos before, you probably know I talk a lot about boundaries. A vertical slice is not that different from a logical boundary. What matters here is that a vertical slice defines a boundary around a use case.
That is the lens I want you to look through, because once you do that, the question of sharing becomes a lot clearer.
A Shipment Workflow Is a Good Example
A good example is a shipment. It is a workflow.
You have different actions that happen along the way that make up a life cycle from beginning to end. Think about ordering something online. It gets dispatched, which means the order is ready to be picked up at the warehouse. The carrier arrives at the shipper. Then the freight is loaded onto the truck. Then it departs. Then it arrives at the destination. Then it is delivered.
That is the workflow.
Now the natural question is this: is the vertical slice the whole workflow, or is each step its own slice?
Because if each step is a slice, how do you share between them?
A Vertical Slice Can Be One Step In the Workflow
Each step in that workflow can be a vertical slice.
You could model the entire workflow as one slice. Sometimes that might be fine. But often, each step can be its own slice because the workflow can change. It can deviate based on the actions that occur.
Take the same shipment example. The order gets dispatched, the vehicle is on the way to the warehouse, it arrives there, and then finds out the order was cancelled. There is nothing to pick up anymore.
That is a different use case.
In shipping, that might be called a dry run.
How do you implement that? It is just another vertical slice. It is part of the workflow, but it is also a deviation from that workflow.
That gets us back to the original question. What can you share between those vertical slices that are part of the same workflow?
There Are Two Different Kinds of Sharing
The first kind of sharing is technical infrastructure and plumbing.
Things like error and result types, logging, tracing, authorization helpers, messaging support, outbox primitives, event bus abstractions, and small utility code. That kind of stuff is normal to share. Some slices will use it. Some will not.
A slice gets to decide what dependencies it takes on and what tactical approach it uses. That is part of the slice owning its implementation.
But that leads to the more important question: what does the slice actually own?
A Vertical Slice Owns Its Data and Behavior
A vertical slice owns its data. That use case owns the data it needs and how that data is persisted.
It also owns the dependencies it takes on. It chooses the tactical patterns it wants to use for that specific use case.
That is important because people hear that and then assume everything must be completely isolated. But that is not really true, especially when several slices are part of the same workflow.
Shared State Is Not the Problem
In the shipment example, what you really have is a state machine. You have state transitions across the life cycle, from dispatched all the way to delivered.
So yes, there is shared state.
That does not mean there is shared ownership of everything.
Imagine a shipment with state like status, dispatched at, arrived at, pallets loaded, and emptied at. If that was mapped to a table, each piece of that state is owned by the slice responsible for that action. The dispatch slice changes the dispatch related state. The arrive slice changes the arrival related state. The loaded slice changes the loaded related state.
Each slice owns the behavior around its part of that workflow.
This Still Applies With Event Sourcing
You can think about the exact same idea with event sourcing.
Instead of changing columns in a table, you are appending events to a stream. Dispatched. Arrived. Loaded. Emptied.
Same concept.
Each use case owns the behavior that produces those events. It owns the data tied to that behavior. It owns where that data lives, whether that is in a table or in an event stream.
That can still all live together. You are still sharing an aggregate. You are still sharing a concern because there are invariants around that workflow.
That is not bad sharing.
Sharing an Aggregate Is Not Bad Sharing
An aggregate is a consistency boundary. You need that consistency boundary around the state.
A slice is a use case.
So if you have several use cases related to the same underlying model, that can be shared. If two slices share validation because both operate on the same domain model, that can be shared too.
At the same time, you can have other slices that are not part of that workflow at all and use a completely different model. That is fine too.
The point is not that every slice must have its own isolated universe. The point is understanding what actually belongs together.
Different Slices Can Use the Same Domain Model
Another way to visualize this is by looking at what each slice does from top to bottom.
One slice might be invoked by an HTTP API. It has application code and a data model under it. Another slice might be invoked by a message or event. It has different infrastructure, different application logic, but still uses the same underlying domain model as the HTTP slice.
The entry point is different. The infrastructure is different. The application code is different.
That does not mean the domain model cannot be shared.
And then you might have another use case that is not related at all, even if it lives in the same broader boundary. That one may have a completely separate model.
Again, the point is that slices define their own dependencies and their own behavior. But that does not mean they cannot share anything.
Where Sharing Becomes a Problem
The problem starts when you begin sharing things that have no business being shared.
In the shipment example, I am talking specifically about the workflow and the shipment life cycle from beginning to end. Nothing in that example has anything to do with compliance, customer support, customer tracking, or what was actually ordered.
Those are separate concerns.
The trap people fall into is that they start sharing and coupling things they should not. The model becomes unfocused. That is how you end up with one giant Shipment object for your whole system.
That is where you get into trouble.
Do not share one god object.
A Vertical Slice Is a Logical Boundary, Not a Physical One
This part is really important.
People often talk about vertical slices in the context of code organization, and that is useful. But a vertical slice is not a physical boundary. It is a logical boundary.
That means it does not have to live in one C#, Java, or TypeScript file. It does not have to live in one project.
If you have a mobile app deployed separately to iOS or Android, and it is dealing with specific actions as part of a use case, that can still be part of the slice. If the same use case is invoked through an HTTP API, that is also part of the slice.
The slice is the logical boundary around the use case. It is not just a folder structure.
Good Sharing Versus Bad Sharing
Good sharing is when vertical slices are operating on the same underlying thing as part of a workflow, a life cycle, or a set of common invariants.
Bad sharing is when a change unrelated to one vertical slice affects another slice unexpectedly.
That is when you are sharing things that have unrelated reasons to change.
That is the distinction.
Do Not Share Domain Meaning
Put another way, do not share domain meaning.
In the shipment workflow, dispatched, arrived, and loaded are use case specific. Dispatch is its own thing. No other feature should be doing something related to dispatch unless it actually owns that behavior.
If dispatch publishes events or changes dispatch related state, that should happen there. If there is state related to dispatching, that slice should own it.
You are not sharing that ownership.
Could you still share an underlying domain model that handles the workflow transitions? Absolutely.
But ownership of behavior still matters.
Focus on Actions, Not Just Data
Hopefully one thing stands out in this example. When I describe vertical slices and use cases, I am describing actions. I am not starting with data.
That matters.
And that is the real issue underneath all of this.
This Is Really About Coupling
When we talk about sharing, what are we really talking about?
Coupling.
That is what this usually comes down to.
If you understand what you are coupling to between vertical slices and use cases, you can manage it. If several slices depend on the same underlying domain model because they are part of the same workflow, that can be perfectly fine.
If every vertical slice can touch any piece of data and change state anywhere, then yes, you are going to have a problem.
At the end of the day, this is about managing coupling.
Share the Right Things
Vertical slices are not about sharing nothing.
They are about sharing the right things.
Technical concerns and plumbing? Sure.
Shared invariants as part of the same workflow? Sure.
A shared aggregate when several use cases are part of the same consistency boundary? Sure.
What you want to avoid is coupling things together that do not belong together.
That is the difference between good sharing and bad sharing.
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.