On the upside, we have the following:

  • We reduce coupling between features, making working on such a project more manageable. We only need to think about a single vertical slice, not N layers, improving maintainability by centralizing the code around a shared concern.
  • We can choose how each vertical slice interacts with the external resources they require without considering the other slices. That adds flexibility since one slice can use T-SQL while another uses EF Core, for example.
  • We can start small with a few lines of code (described as Transaction Scripts in Patterns of Enterprise Application Architecture, by Martin Fowler) without extravagant design or over-engineering. Then we can refactor our way to a better design when the need arises and patterns emerge, leading to a faster time to market.
  • Each vertical slice should contain precisely the right amount of code needed to be correct—not more, not less. That leads to a more robust codebase (less code means less extraneous code and less code to maintain).
  • It is easier for newcomers to find their way around an existing system since each feature is near-independent, leading to a faster onboarding time.
  • All patterns and techniques you learned in previous chapters still apply.

From my experience, features tend to start small and grow over time. The users often find out what they need while using the software, changing the requirements over time, which leads to changes in the software. After the fact, I wish many projects I worked on were built using Vertical Slice Architecture instead of layering.

Disadvantages

Of course, nothing is perfect, so here are some downsides:

  • It may take time to wrap your head around Vertical Slice Architecture if you’re used to layering, leading to an adaptation period to learn a new way to think about your software.
  • It is a “newer” type of architecture, and people don’t like change.

Another thing that I learned the hard way is to embrace change. I don’t think I’ve seen one project end as it was supposed to. Everyone identifies the missing pieces of the business processes while using the software. That leads to the following advice: release the software as fast as possible and have your customers use the software as soon as possible. That advice can be easier to achieve with Vertical Slice Architecture because you build value for your customers instead of more or less valuable abstractions and layers. Having a customer try staged software is very hard; no customer has time to do such a thing; they are busy running their business. However, releasing production-ready slices may lead to faster adoption and feedback.

At the beginning of my career, I was frustrated when specifications changed, and I thought that better planning would have fixed that. Sometimes better planning would have helped, but sometimes, the customer just did not know how to express their business processes or needs and had to try the application to figure it out. My advice here is don’t be frustrated when the specs change, even if that means rewriting a part of the software that took you days or more to code in the first place; that will happen all the time. Learn to accept that instead, and find ways to make this process easier and faster. If you are in contact with the customers, find ways to help them figure out their needs and reduce the number of changes.