Vertical Slices in software architecture are pictured right now as the best thing since sliced bread. I won’t try to hide that, like it. I've written about CQRS and Vertical Slices over the years - how to slice the codebase effectively, shown examples, and explained why generic doesn't mean simple, yet…I still get questions about Vertical Slices Architecture (VSA). After a recent Discord discussion, I want to share some additional thoughts on how I see Vertical Slices Architecture, how it relates to CQRS, what different slicing strategies are, and (of course) the tradeoffs.
I’ve noticed a lot of confusion between VSA (Vertical Slice Architecture) and the concept of a “modular monolith,” which gained popularity after the initial hype around microservices faded and the term monolith began to lose its exclusively negative connotations.
One common issue is deciding whether a module should be treated as the same thing as a feature, command, or query. If so, the tendency is to make each module completely independent, often resulting in separate schemas and tables for different modules, multiple EF contexts, and similar design choices.
I believe that when people see a vertical slice drawn on a VSA chart extending down through the database layer, they often interpret it as “this slice must operate on a dedicated portion of the database.” While this approach is not inherently wrong, in many cases it is unnecessary.
Unfortunately, the terminology like microservices, modular monolith, VSA, CQS, CQRS etc. has become quite diluted.
Yup, fully agreed, and that's why I wrote this article and why I added explicit section about semantic diffusion. I think that again specific practices that people were doing were elevated to "best practices" or "The Practices" losing the original context and the intention behind those patterns.
I love the approach and going to the roots of CQRS which is not as complex pattern as people tend to think. Sometimes I struggle with where to put common infrastructure level code. For example for couple of features I need to read shopping cart entity. What do you think about extracting such code to separate folder/package and creating repo/dao facade to be used in different features? I believe that in big projects there might be more aspects like that, example: infrastructure logic to publish message to certain queue. Any recommendations?
I’ve noticed a lot of confusion between VSA (Vertical Slice Architecture) and the concept of a “modular monolith,” which gained popularity after the initial hype around microservices faded and the term monolith began to lose its exclusively negative connotations.
One common issue is deciding whether a module should be treated as the same thing as a feature, command, or query. If so, the tendency is to make each module completely independent, often resulting in separate schemas and tables for different modules, multiple EF contexts, and similar design choices.
I believe that when people see a vertical slice drawn on a VSA chart extending down through the database layer, they often interpret it as “this slice must operate on a dedicated portion of the database.” While this approach is not inherently wrong, in many cases it is unnecessary.
Unfortunately, the terminology like microservices, modular monolith, VSA, CQS, CQRS etc. has become quite diluted.
Yup, fully agreed, and that's why I wrote this article and why I added explicit section about semantic diffusion. I think that again specific practices that people were doing were elevated to "best practices" or "The Practices" losing the original context and the intention behind those patterns.
Also, I wrote that the trend "Monolith First" is dangerous and not always best advice in general here: https://www.architecture-weekly.com/p/monolith-first-are-you-sure.
I love the approach and going to the roots of CQRS which is not as complex pattern as people tend to think. Sometimes I struggle with where to put common infrastructure level code. For example for couple of features I need to read shopping cart entity. What do you think about extracting such code to separate folder/package and creating repo/dao facade to be used in different features? I believe that in big projects there might be more aspects like that, example: infrastructure logic to publish message to certain queue. Any recommendations?
Really, really nicely described and explained. Thanks so much for writing this article.