Three versions of the follow-up now stand in kladde-stile, and all three are cut by the same principle: by the technical job of a piece of
code. Version A separates presentation, business logic and data access, B adds domain and application, C middle and adapters.
The change "weekly" ran straight through all three: four files in three layers in A, five in three projects in B, three in two projects in C.
Lesson 4.10.1 described the fifth style as the reverse. Instead of "what technical job does this code have?" it asks "which feature does it belong to?". This lesson builds the follow-up that way, as version D, measures it like the others and settles the three questions on which the style succeeds or fails: How much duplication is allowed, where do the rules stay, and does it need a library for this?
Vertical slice has no page of its own in Microsoft's documentation. This lesson therefore explains the style itself. Where Microsoft's guides touch the idea in passing, it says so.
Cutting by use case
A slice is a vertical cut through all technical jobs of a use case: the endpoint that accepts the request, the logic that decides, and the data access that reads or stores. All of it lives in one folder, and every use case has its own. This is what the path of "complete" looks like in the four versions:
| Version | Where the code for "complete" lives |
|---|---|
| A Layers | an endpoint in FollowUps.Web/FollowUpEndpoints.cs, FollowUpService.CompleteAsync in Business, FollowUpRepository in Data |
| B Clean | an endpoint in Web, CompleteFollowUp in Application, EfFollowUpRepository in Infrastructure, FollowUp.Complete in Domain |
| C Hexagonal | an endpoint in FollowUps.Http, FollowUpUseCases.CompleteAsync and FollowUp.Complete in Core, SqlFollowUpStore in Sql |
| D Slices | Features/CompleteFollowUp/CompleteFollowUpEndpoint.cs and FollowUp.Complete in the folder Domain |
Behind it stands the same question as behind every style, from lesson 4.10.1: What changes together? Layers answer "everything that uses the same technology". Slices answer "everything that belongs to one feature". When a feature is added, that is a new folder, and no existing file has to open. When a feature changes, the change often stays in its folder.
Microsoft's guide "Develop ASP.NET Core MVC apps" (under Further reading) knows the first half of this idea under the names feature folders or feature slices: ordering code by feature instead of by kind of file, for an API one folder per feature with its endpoints and their DTOs. Vertical slice goes one step further and also brings logic and data access into the folder.
Two things follow from it that you did not have in the first three versions:
- Every slice chooses its own means. The list of due follow-ups needs no aggregate, it reads and shows. Its slice asks the database directly and maps the result onto the response in the same query. Completing, on the other hand, changes something and therefore loads the model, lets it decide and stores. Two slices, two ways, without one disturbing the other.
- There is no layer that all share. No service with all methods, no repository with all queries. What two slices need in common has to earn the right first; more on that in a moment.