Deciding where shared logic lives is the most critical moment in Vertical Slice Architecture adoption, as choosing incorrectly reintroduces the coupling the architecture aims to eliminate. This article proposes a three-tier approach to sharing code that balances technical infrastructure, domain concepts, and local feature logic.

MilanJovanovic's platform  covers topics related to software development, technology trends, and coding tutorials. Through articles, tutorials, and code examples, MilanJovanovic offers insights into programming languages, development frameworks, and best practices in software engineering. Readers can learn about software design principles, development methodologies, and emerging technologies to enhance their coding skills and build high-quality software applications.

Milan Jovanović

Vertical Slice Architecture offers flexibility but creates challenges around shared code placement. The article proposes a three-tier framework: freely share technical infrastructure (logging, database connections), push domain logic into entities and value objects, and keep feature-specific logic local within feature folders. Cross-feature sharing should be minimized—most cases are actually data access in disguise. The key principle is that duplication is often cheaper than premature abstraction, and code should be organized by its nature (domain, infrastructure, or cross-cutting) rather than forced into a common junk drawer.

Vertical Slice Architecture: Where Does the Shared Logic Live?

This article solution is Clean Architecture masquerading as Vertical slice.
From the article: “You build a CreateOrder slice. Then UpdateOrder. Then GetOrder. Suddenly, you notice the repetition. The address validation logic is in three places. The pricing algorithm is needed by both Cart and Checkout.”
This is the problem right there, you don’t create a “slice” or “project” for things that belong to the same “feature”. The feature is the slice!
Repositories are created on the slice itself. If you need some generic data access abstraction, create it on a separate project and import it on features (slices) that need it.
Eventually you will need shared entities between slices, create class library project for that, keep dependencies on it close to 0.
Here is an example of the structure:
/src
<ul>
<li>/Orders
<ul>
<li>/Controllers</li>
<li>/Requests
<ul>
<li>/GetOrder</li>
<li>/CreateOrder</li>
</ul>
</li>
<li>/Repositories</li>
<li>/Validators</li>
<li>/Services</li>
<li>/Migrations</li>
<li>/BackgroundTasks</li>
<li>/Entities</li>
</ul>
</li>
<li>/Orders.Abstractions (if you need to share entities, event handlers, constants, with other feature projects)</li>
<li>/DataAccess (if you need a wrapper or abstraction for EF or another database)</li>
<li>/ExternalAPI (Like KeyVault or another external API abstraction)</li>
</ul>