What is the difference between Vertical Slice Architecture and Feature-Based Architecture

Question

I am refactoring my monolithic application, in which the code is organized based on layered architecture.

I want to implement Modulith (Modular Monolit) in my app, but I've run into a problem: I haven't found this architecture anywhere in its pure form, but I've found two ways to organize the code (as far as I understand) - Vertical Slice Architecture and Feature-Based Architecture.

Now, I can't understand what is the key difference between Vertical Slice Architecture and Feature-Based Architecture. Is FBA a subtype of VAS, a specific implementation of VAS, or none of the above?

Below, I will give an example of Feature-Based architecture directly in the IDE, which I found while searching for information on the subject.

com 
+- example 
 +- myapplication 
 +- MyApplication.java 
 | 
 +- customer 
 | +- Customer.java 
 | +- CustomerController.java 
 | +- CustomerService.java 
 | +- CustomerRepository.java 
 | +- order 
 | +- Order.java 
 | +- OrderController.java 
 | +- OrderService.java 
 | +- OrderRepository.java
 | +- config
 | +- ...
 | +- common
 | +- exception
 | +- ...

I've tried to find some information for long time, but I didn't understand at all how they differ. The only thing I understand now is that both VSA and FBA is not architecture in the literal sense, but rather a way of organizing code. If I am wrong about this, then the error lies in a fundamental understanding of the issue, and I would be grateful if you could point out my mistake.

UPD: Links

Initially, I found information about Spring Modulith, which, as I understood, is Spring's recommendations for building modular architecture.

Next, I wanted to understand how exactly to organize the code, i.e., what to include in each folder (package), and came across the following articles: Master Spring Boot Feature Based Architecture, as well as a comparison of Packaged by Layer (Layer-based) vs Packaged by Feature (Feature-based).

Then, I came across a specific example of organizing Feature-based modular code in Java. At the very end of my search, I found Vertical Slice Architecture and Comparison with Clean Architecture, which is where I learned about the existence of VSA, which I then began to read about in more depth.

Further searches yielded nothing, as I was ultimately unable to find information about how they differ.

• Greg Burghardt: Can you also edit your post to include your current understanding of each architecture? It's hard to pinpoint the confusion still.
• Ice K: @GregBurghardt The main reason for the confusion is that I cannot understand why these architectures were given different names. I read the answer I was given and realized that such situations do happen...
• Greg Burghardt: Fair enough. And good to know I'm not the only one who felt that.
• Doc Brown: Recommended readings: Don’t Let Architecture Astronauts Scare You and Architecture astronauts take over After reading this, ask yourself whether you are really solving the right problem by trying to shoehorn your current application into some nice-sounding architecture buzzword.
• Ice K: @DocBrown thank you! I'm not trying to pretend to be an expert on architecture, I just think that when it comes to looking for a job as a junior developer, some interviews may ask questions about architecture, which is why I'm trying to push the application into them to understand how they work.

Answer 1

Both are, if not the same, at least very similar—I would bet that the different communities came with the same concept roughly at the same time, and ended up with two different names.

This being said, don't spend too much time searching for the right term. Correct terminology is useful when you talk to someone about your code, and the person you talk to knows the terminology as well as you do. For instance, if we both work on the same project, and we both know what a factory pattern is, it's much faster to say: "this constructor is getting out of hand; let's use the factory pattern here," rather than trying to explain what a factory pattern is, without using the actual word. Now, if, say, I have no idea about design patterns, using fancy words won't improve our communication in any way. Same here: you can write in your documentation that you are using vertical slice architecture—if most of your readers don't know what that is, it won't help.

Do, however, spend time understanding what the different approaches bring. And here, I'm referring to your example of organizing code, that is not particularly illustrative of neither vertical slice architecture, nor feature-based architecture. While you did get the point that the organization of code follows a feature-thing vertical approach, another, more important benefit is that different features can use different approaches. For instance, you can have one feature that accesses a database through an ORM, while another one would just execute an SQL query. One may have five layers. Another one—only two. And that's the point—to be able to pick the most appropriate approach for a particular feature.

Push it to the extreme, and you'll get microservices, where not only different approaches in terms of layers can be used, but even technologies may totally differ: for the same end user application, one service may be written in Ruby and use Elasticsearch, while the other would be in C++ and use PostgreSQL.

• Ice K: Thank you very much for your reply and advice. I haven't been developing for very long, and this is essentially my pet project, where I hone my programming skills and try to understand all aspects as deeply as possible so as not to make silly mistakes that could lead me down the wrong path for a long time. In fact, this example is related to the fact that, in reality, I still don't understand the difference between the approaches at a sufficient level, since just a week ago there were only three approaches for me: monolith, modular monolith, and microservices :D...
• Ice K: In fact, in my attempts to understand how to properly structure code in a project, I fell down a rabbit hole of DDD, Layered Architecture, Clean Architecture, etc. As a result, trying to make sense of this chaos, I decided to start with practical ways of organizing code, and fell down a second rabbit hole from the first. But now I at least have a clear understanding that substance is more important than terminology.