Getting Started with Vertical Slice Architecture

This chapter introduces Vertical Slice Architecture, an effective way to organize our ASP.NET Core applications. Vertical Slice Architecture moves elements from multiple layers to a feature-oriented design, helping us maintain a clean, simple, cohesive, loosely coupled, and manageable codebase.

Vertical Slice Architecture flips our architectural perspective toward simplified architecture. Historically, we divided the logic of a feature across various layers like UI, business logic, and data access. With Vertical Slice Architecture, we create independent slices of functionality instead. Think of your application as a rectangular cake; instead of cutting it horizontally (layers), we’re cutting vertically (features), with each slice being fully functional on its own.

This style changes how we design and organize our project, testing strategies, and coding approach. We don’t have to worry about bloated controllers...

Vertical Slice Architecture

Instead of separating an application horizontally (layers), a vertical slice encapsulates all horizontal concerns within a single feature scope. Here is a diagram that illustrates that:

Figure 17.1: Diagram representing a vertical slice crossing all layers

Jimmy Bogard, who is a pioneer and proponent of this type of architecture, wrote the following:

”[The goal is to] minimize coupling between slices and maximize coupling within a slice.”

What does that mean? Let’s split that sentence into two distinct points:

• “minimize coupling between slices” (improved maintainability, loose coupling)
• “maximize coupling within a slice” (cohesion)

We could see the former as saying that one vertical slice should not depend on another, so when you modify a vertical slice, you don’t have to worry about the impact on the other slices because the coupling is minimal...

Summary

This chapter provided an overview of Vertical Slice Architecture, which flips layers by 90°. Vertical Slice Architecture is about writing minimal code to generate maximum value by getting superfluous abstractions and rules out of the equation by relying on the developers’ skills and judgment instead.

Refactoring is critical in a Vertical Slice Architecture project; success or failure will most likely depend on it. We can also use any patterns with Vertical Slice Architecture. It has lots of advantages over layering, with only a few disadvantages. Teams who work in silos (horizontal teams) may need to rethink switching to Vertical Slice Architecture and first create or aim at creating multi-functional teams instead (vertical teams).

We replaced the low-value abstraction with commands and queries (CQS-inspired). Those are then routed to their respective Handler using the Mediator pattern (helped by MediatR). That allows encapsulating the business logic and...

Questions

Let’s take a look at a few practice questions:

1. What design patterns can we use in a vertical slice?
2. When using Vertical Slice Architecture, is it true that you must pick a single ORM and stick with it, such as a data layer?
3. What will likely happen if you don’t refactor your code and pay the technical debt in the long run?
4. What does cohesion mean?
5. What does tight coupling mean?

Further reading

Here are a few links to build upon what we learned in the chapter:

• For UI implementations, you can look at how Jimmy Bogard upgraded Contoso University:
  1. Contoso University on ASP.NET Core with .NET Core: https://adpg.link/UXnr
  2. Contoso University on ASP.NET Core with .NET Core and Razor Pages: https://adpg.link/6Lbo
• FluentValidation: https://adpg.link/xXgp
• AutoMapper: https://adpg.link/5AUZ
• MediatR: https://adpg.link/ZQap

Answers

1. Any pattern and technique you know that can help you implement your feature. That’s the beauty of Vertical Slice Architecture; you are limited only by yourself.
2. No, you can pick the best tool for the job inside each vertical slice; you don’t even need layers.
3. The application will most likely become a Big Ball of Mud and be very hard to maintain, which is not good for your stress level, the product quality, time to market of changes, and so on.
4. Cohesion means elements that should work together as a united whole.
5. Tight coupling describes elements that cannot change independently and that directly depend on one another.

Learn more on Discord

To join the Discord community for this book – where you can share feedback, ask questions to the author, and learn about new releases – follow the QR code below:

https://packt.link/ArchitectingASPNETCoreApps3e