The morning usually starts innocently. Someone opens a pull request to add a small payment rule, and the file list looks longer than the change feels. One controller, one service, one repository, one mapper, one validator, one test file in a different folder, and a small shared helper that nobody is fully sure about. The rule itself is simple. The path to place it is not.
This is where architecture stops being a diagram and becomes a daily feeling. A layered codebase can look beautifully organized from the outside. Controllers live with controllers. Services live with services. Repositories live with repositories. It is easy to teach, easy to generate, and easy to recognize when a team is new. The folders feel tidy because each folder answers the question, what kind of code is this?
Vertical slice architecture asks a different question: what user or business change does this code belong to? Instead of spreading a feature across technical layers, it keeps the route, input validation, use case, data access, and tests close to the thing being shipped. A slice might be called create-invoice, approve-refund, or change-email-address. The folder reads less like a framework tutorial and more like the product itself.
Layered architecture is not wrong. For a small application, it can be kind. New engineers know where to look. Shared conventions are obvious. If the whole team works across the whole codebase, grouping by technical responsibility may be enough. The trouble appears slowly, usually after the tenth or twentieth feature. A change that should feel local begins to touch every layer. Reviewers need to jump around. Deleting an old feature becomes archaeological work because its pieces are scattered across folders that also contain everything else.
Vertical slices reduce that blast radius. If refund approval changes, most of the work happens inside the refund approval slice. Tests sit near the behavior. The use case can have its own small model without pretending every concept must be shared globally. This does not remove layers. It simply makes them internal to the feature. The technical structure is still there, but it is no longer the first thing the codebase says about itself.
The tradeoff is discipline. Vertical slices can become many tiny islands if teams do not agree on naming, shared utilities, and boundaries. Copying a small mapper twice may be better than creating a shared abstraction too early, but copying everything forever becomes another kind of debt. A healthy vertical-slice codebase needs a calm rule: share only when the duplication has proven that it is the same idea, not merely the same shape.
I like to think of this choice through the rhythm of change. If the work usually arrives as product capabilities, vertical slices make the code follow the work. If the work usually arrives as platform improvements or cross-cutting technical changes, layers may still feel natural. Many teams land in the middle: feature folders at the top, small layers inside each feature, and a deliberately boring shared folder for things that have truly become common.
The migration does not need to be dramatic. Pick one new feature and build it as a slice. Keep the public boundary small. Move only the code that changes together. Let the next feature teach you whether the shape helps. Architecture improves most honestly when it follows repeated evidence rather than one strong meeting opinion.
The quiet takeaway is that structure should reduce the distance between intention and change. If a developer can read the folder name, understand the business action, make the change, test it, and leave the rest of the system alone, the architecture is doing useful work. If every small change feels like walking through every layer of the building to switch on one light, it may be time to try a slice.
If your team has moved from layers to slices, or decided to stay layered on purpose, I would be curious what signal made the choice clear for you.