I've long been a proponent of this vertical slicing approach. When do you ever need to look at another feature's controller, view or model when working on a particular feature? The mental load is significantly greater, and onboarding new developers is much harder.
Thanks for this great article ! Could it work with projects relying en different languages, for instance typescript (React) for frontend and java (Spring) for backend ? I wonder if we could go as far as mixing tsx files and java files in slice folders. Configuring build systems (vite + maven) could be quite challenging.
That would be quite a dream, but I must admit that the language boundary between TSX (with React) and Java is very different from that between merely HTML and CSS. In the latter case, we have two languages that are meant to be used together while the former case are admittedly two polar-opposite ecosystems. As much as I hate to admit it, the dream of a vertically sliced architecture doesn't make much sense in this context.
I do love the dream of it, though! Maybe we'll figure it out some day... 🙏
The Angular Team recently merged their Angular style Guide and now recommend a pattern similar to this where they recommend a feature based file organization. github.com/angular/angular/pull/60...
I also have maintained businesses with this concept of separate applications, or also referred to as modules, or better yet organizing independent applications that can work independently on their own. Amazon called this decoupled architecture. For business minded folks, avoiding the monolithic app at all levels is critical to being capable of easily pivoting as well as putting a cost on your assets/intellectual property.
I've been using this method myself for a bit and seemed to naturally happen when I moved from Backbone and Marionette many years ago to React. I never really thought about it as vertical slicing though, nice article.
That's something I've realized within myself and my own circle of colleagues, too! It's like we all somehow independently converged on this pattern of vertically slicing our features. Given the independent validation, I think that makes it even more appealing.
pretty cool seeing folks push for more feature-driven setups - tbh i've always gotten lost digging through layers. you ever feel like habits from old patterns get in the way of trying new stuff?
love seeing thishonestly, searching all over for files always messes me up way more than it should. you ever wonder if most old habits in programming actually slow us down more than help?
VMVC make life easier than complicated. Be smart and stash all assets like images, fonts, and icons on a CDN. Just use the full URL when you need it. It's super simple when you wanna swap things out without the hassle of redeploying everything.
Oh, and one more thing - if you can make magic happen with Node.js and React/Angular/Vue, stick with those. No need to complicate life with Next.js.
Nice article. Btw I think this is still MVC architecture . Folder structure does not impose an architecture . Vertical slice is done through messaging btw feature slices.( and if this is the way you done it , then sorry, haven't looked at the source code)
That's true! The heart of what I was getting at in this article is the shift in perspective from the strictly horizontal layers of MVC to the more end-to-end vertical layers of feature-driven architectures.
To your point: folder structures are indeed somewhat incidental to the chosen architecture, but it is admittedly heavily influenced by our mental framework of that architecture. This article seeks to reconsider that mental framework while keeping some spirit of MVC alive. An excerpt from the article:
Interestingly, though, the MVC patterns have not totally disappeared even in a vertically sliced architecture—as evidenced by the internal model.ts, controller.ts, and view.tsx files within a particular feature module. The slicing is different, yet the MVC-style separation of concerns remains in spirit.
Vertical slice is done through messaging btw feature slices
I believe this is especially applicable to web applications (as in my examples), where the request-response cycle is quite literally messaging at its core. 😉
Consider a POST request from a <form>. An end-to-end feature module spans the UI, the server endpoint, and the database operations. This is an entire vertical slice.
This is such a clean articulation of a problem so many devs face but rarely address head-on. Vertical slicing aligns way better with how modern teams scale — especially when working across cross-functional domains, feature flags, or parallel delivery tracks.
At [turtal-docs.in/], we're leaning heavily into vertically sliced systems to support our open-source contributor ecosystem. Each feature module owns its data flow, logic, and UI — reducing inter-slice dependencies and making code reviews and onboarding way easier.
We're also ranking and rewarding contributors based on the quality and impact of their feature modules. If you're building or contributing to OSS with strong architectural discipline, we'd love to have you onboard and feature your work.
Building IT solutions that actually work. 20+ years in the industry, focused on Azure, DevOps, and system architecture grounded in logic—not buzzwords.
It does look sorta like that, but that isn't really the spirit of the article. What I'm advocating for is an end-to-end vertical slicing of a codebase according to feature modules such that the data flow from the model to the presentation layer is a self-contained pipeline.
I must reiterate: there is no explicit notion of a "controller" here—only data pipelines.
I've long been a proponent of this vertical slicing approach. When do you ever need to look at another feature's controller, view or model when working on a particular feature? The mental load is significantly greater, and onboarding new developers is much harder.
Great article!
And if you do, it may be a hint you are on a questionable track/path
Thanks for this great article ! Could it work with projects relying en different languages, for instance typescript (React) for frontend and java (Spring) for backend ? I wonder if we could go as far as mixing
tsx
files andjava
files in slice folders. Configuring build systems (vite + maven) could be quite challenging.That would be quite a dream, but I must admit that the language boundary between TSX (with React) and Java is very different from that between merely HTML and CSS. In the latter case, we have two languages that are meant to be used together while the former case are admittedly two polar-opposite ecosystems. As much as I hate to admit it, the dream of a vertically sliced architecture doesn't make much sense in this context.
I do love the dream of it, though! Maybe we'll figure it out some day... 🙏
The Angular Team recently merged their Angular style Guide and now recommend a pattern similar to this where they recommend a feature based file organization. github.com/angular/angular/pull/60...
I also have maintained businesses with this concept of separate applications, or also referred to as modules, or better yet organizing independent applications that can work independently on their own. Amazon called this decoupled architecture. For business minded folks, avoiding the monolithic app at all levels is critical to being capable of easily pivoting as well as putting a cost on your assets/intellectual property.
I've been using this method myself for a bit and seemed to naturally happen when I moved from Backbone and Marionette many years ago to React. I never really thought about it as vertical slicing though, nice article.
That's something I've realized within myself and my own circle of colleagues, too! It's like we all somehow independently converged on this pattern of vertically slicing our features. Given the independent validation, I think that makes it even more appealing.
You call it features I see modules, but whatever the name it has the same goal, breaking the code down in more manageable pieces.
pretty cool seeing folks push for more feature-driven setups - tbh i've always gotten lost digging through layers. you ever feel like habits from old patterns get in the way of trying new stuff?
Yeah this nails the stuff I’ve struggled with in big projects. Keeping each feature in its own spot just keeps me sane.
love seeing thishonestly, searching all over for files always messes me up way more than it should. you ever wonder if most old habits in programming actually slow us down more than help?
Embracing a vertically sliced architecture turns sprawling MVC layers into self-contained feature modules, reducing context-switching and boosting maintainability.
VMVC make life easier than complicated. Be smart and stash all assets like images, fonts, and icons on a CDN. Just use the full URL when you need it. It's super simple when you wanna swap things out without the hassle of redeploying everything.
Oh, and one more thing - if you can make magic happen with Node.js and React/Angular/Vue, stick with those. No need to complicate life with Next.js.
Nice article. Btw I think this is still MVC architecture . Folder structure does not impose an architecture . Vertical slice is done through messaging btw feature slices.( and if this is the way you done it , then sorry, haven't looked at the source code)
That's true! The heart of what I was getting at in this article is the shift in perspective from the strictly horizontal layers of MVC to the more end-to-end vertical layers of feature-driven architectures.
To your point: folder structures are indeed somewhat incidental to the chosen architecture, but it is admittedly heavily influenced by our mental framework of that architecture. This article seeks to reconsider that mental framework while keeping some spirit of MVC alive. An excerpt from the article:
I believe this is especially applicable to web applications (as in my examples), where the request-response cycle is quite literally messaging at its core. 😉
Consider a
POST
request from a<form>
. An end-to-end feature module spans the UI, the server endpoint, and the database operations. This is an entire vertical slice.This is such a clean articulation of a problem so many devs face but rarely address head-on. Vertical slicing aligns way better with how modern teams scale — especially when working across cross-functional domains, feature flags, or parallel delivery tracks.
At [turtal-docs.in/], we're leaning heavily into vertically sliced systems to support our open-source contributor ecosystem. Each feature module owns its data flow, logic, and UI — reducing inter-slice dependencies and making code reviews and onboarding way easier.
We're also ranking and rewarding contributors based on the quality and impact of their feature modules. If you're building or contributing to OSS with strong architectural discipline, we'd love to have you onboard and feature your work.
Yeh, it is funny to read articles like this.
The truth is that there is no right answer, it is always about a tradeoff.
Sounds like HMVC from the early 2000s to me
It does look sorta like that, but that isn't really the spirit of the article. What I'm advocating for is an end-to-end vertical slicing of a codebase according to feature modules such that the data flow from the model to the presentation layer is a self-contained pipeline.
I must reiterate: there is no explicit notion of a "controller" here—only data pipelines.
Sounds interesting, thanks for the article!
Great post!
You're just describing FSD (feature sliced design)
feature-sliced.github.io/documenta...
Nice post
This is awesome!