History

Architecture is a certainty in software development. There have been many architectures over the years, and you can find a plethora of information on Google.

The history of just Vertical Slice Architecture is a bit more recent. The term was coined by Jimmy Bogard in 2018. However, the ideas behind it have been around for a while.

2015

In fact, as early as 2015, Jimmy was talking about SOLID Architecture which is essentially the same thing. It had a few key points (from his slides):

• SRP - One class per feature/concept
• OCP - Extend through cross-cutting concerns
• LSP - Just don't do inheritance
• ISP - Separating queries from commands
• DIP - Save for true external dependencies.

The key points of the SOLID architecture were really applying the principals to achieve a highly cohesive codebase in regard to the Domain specific code (SRP, ISP). The Domain specific code was then extended (OCP) via cross-cutting concerns - like authentication, authorization & generic logging.

A lot of the outcomes from this talk to me, was allowing a simpler architecture for what matters most - the Domain. The most important thing in software, is that it works. The architecture that allows you to deliver features quickly, is the best architecture for you.

2018

Moving along a few years, in 2018, Jimmy wrote a blog post called Vertical Slice Architecture. This was the first time the term was used. It was then shortly followed up with a presentation at NDC Sydney later that year.

The key points of this evolution of the architecture were (from the presentation):

• CQRS - e.g. HTTP GET is safe & idempotent, POST is Unsafe & not idempotent. Represent this two different concerns in different models/classes where this was just one.
• Vertical Slicing makes it easy to modify code
• Do not skip the refactor step in Red-Green-Refactor. (Common complaints about 'simple' architectures is due to this)
• Push behaviour down (i.e. Focus on a rich domain & allow handlers to do the 'ugly' work, like data access)
• Integration test handlers & unit test Domain

Where it was left

At that point, Jimmy has set the world up with some pretty nice foundations.

1. Logically split application reads & writes using CQRS.
2. CQRS models are use cases. Application use cases should be sliced & tightly coupled within
3. Refactor repeated logic into a rich Domain
4. Refactor repeated domain-agnostic code into services, repositories
5. Integration test use cases
6. Unit test the Domain