> For the complete documentation index, see [llms.txt](https://hanfak.gitbook.io/workspace/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://hanfak.gitbook.io/workspace/general-paradigms/architecture/patterns/vertical-slice.md). # Vertical Slice architecture ## What? * “vertical slice” being a crossection of code that runs from the front-end deep down to the data layer * The goal is to minimize coupling between slices and maximize coupling within a slice. * is built around distinct requests, encapsulating and grouping all concerns from front-end to back. * Vertical Slice Architecture aims to separate the code by features, aiming to minimize code sharing between features. * similar idea to microservices, but no talking between each other * It focuses not on the separation of concerns from a technical perspective (like domain vs. infrastructure vs. application logic) but from the perspective of reflecting the business domain’s features. ## Why/benefits * Covers issues found in onion/layered architecture * these architectures tend to be mock-heavy, with rigid rules around dependency management * Exposion of abstractions that are not needed * treat each request as a distinct use case for how to approach its code. * More teams can work on different parts of the code (different use cases) with out intefering with each other (ie merge issues) * Context switching becomes less of a problem as everything related to that feature is in the current namespace. There’s no need to follow code down a rabbit hole across the application. * the benefit of file proximity * the principle of high cohesion: things that change together ought to live together. * Less confusing to new developers * Change requests from users or the business tend to be vertical in manor, so it makes sense to architect our application vertically as well. It is not often that you get a change request for something that is horizontal in nature. * Dont need abstractions early on (yagni), can leave for later * Dont need to change external dependencies, so planning for this might not be necessary * Each vertical slice can have different dependencies (similar to microservices) * ie one slice can use sql another can use orm * Liftability, can copy slices to other projects * Easy to split into microservices * improve cohesion * within slice, everything is coupled, * but this can lead to either have a commons package or duplicating common infrastructure code ## Common patterns invovled * SOLID in sliced ## How * Vertical slices should be isolated. One vertical slice should not reach outside of it’s namespace and it should definitely not call into another vertical slice. ## Testing ## Downsides * can lead to a lot of duplication * Need to have some form shared code that reduces duplication, but can lead to issues if multiple people working on it * Testing becomes hard at unit level, as less indirection (interfaces for dependencies), hard to mock a database dependency and test business logic in memory * More end to end testing of whole slice * If using pure slices, then domain (objects and language) used could end up being different in different slices within same app * Use shared domain model ## Links * Jimmy Bogard * Jimmy Bogard same * * * * Vertical Slice Architecture, not Layers! - codeopinion --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://hanfak.gitbook.io/workspace/general-paradigms/architecture/patterns/vertical-slice.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.