secture & code

Vertical Slices 101

Where does the Vertical Slices pattern come from?

After having talked for some time about different models of Clean Architectures, I would like to introduce a pattern that discusses its effectiveness, or at least its advantages in the short/medium term.

The pattern Vertical Slices was created by Jimmy Bogard as a response to the already traditional clean architectures (Hexagonal or Ports&Adapters, Onion, Screaming...)

Clean Architecture (always according to Jimmy), it forces you to follow a series of dependency rules that involve creating a lot of abstractions in exchange for very little benefit, since the main goal of Clean Architecture is to eliminate dependence on any framework or third-party library.

The real benefit of these abstractions and rules is hardly noticeable, since it has never been the case of having to change Framework or database (except maybe when running batteries of tests). But following rules for the sake of following them doesn't suit Jimmy (or anyone else, I guess), so he proposed his own architecture model.

What is the Vertical Slices pattern?

With a pattern of Clean Architecture we make a separation by layers, usually Infrastructure (third-party library adapters), Application (business logic) and Domain (abstractions and contracts).

Jimmy's proposal is that, instead of dividing our code into layers for technical reasons, we divide it by functionality. Each functionality will be a slice y will group all these layers together. In this way, each functionality is a different use case with different needs that will be addressed in the most appropriate way.

It could be understood as an independent module within the project, which controls from the request to the response independently (this, inevitably, leads us to think about CQRS).

The essence of Vertical Slices Architecture lies in minimizing the coupling between slices, maximizing in turn the coupling at each slice (axes of change).

When adding or changing a feature in an application, I'm typically touching many different “layers” in an application. I'm changing the user interface, adding fields to models, modifying validation, and so on. Instead of coupling across a layer, we couple vertically along a slice. Minimize coupling between slices, and maximize coupling in a slice.

With this approach, the shared layers disappear and abstractions become unnecessary, each slice only implement what you need, and each slice decides how to handle the request assigned to it.

The Domain Logic Patterns Martin Fowler's decisions are no longer a project-wide decision, but rather, each project is slice is self-managed and decides which ones to use and when to use them. This makes it easier to start any slice as simply as possible and refactor to patterns as needed, in due course.

Disadvantages

Jimmy himself recognizes that this pattern is not for all teams, since they must have a certain maturity and experience in detecting code smells and in applying refactors following the classic techniques of the book Refactoring to Patterns by Joshua Kerievsky, moving complex logic to a shared domain layer (if and when it is really necessary)

Conclusion

Reading about a pattern that contradicts an upward trend such as the Clean Architectures is always extremely interesting, as we can reflect on what we are doing and why we are doing it (are we following rules for the sake of following them?).

However, in my opinion, this pattern favors the lack of coherence between the different functionalities of a project, making you have to learn again how it is designed or implemented in each one you are going to touch.

It may be an ideal approach in very large projects with clearly defined teams and clearly different ways of working or needs, something like applying microservices at a monolithic level but I think that, in smaller projects or with a frequent rotation between who is going to work on what functionality, it contributes more to chaos.

I do think it is an interesting exercise from the point of view that, by going through different functionalities with different implementations, we can detect which patterns or techniques are being useful in others. slices and see about incorporating them into others, thus eliminating patterns implemented only because they have been useful in another part of the application. However, it seems to me a lengthy process that may make sense when working in product companies, but not very favorable when working on shorter projects.