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.
- Logically split application reads & writes using CQRS.
- CQRS models are use cases. Application use cases should be sliced & tightly coupled within
- Refactor repeated logic into a rich Domain
- Refactor repeated domain-agnostic code into services, repositories
- Integration test use cases
- Unit test the Domain