Clean, Onion or Vertical Slice Architecture. Which one is better?

I get this question from time to time by developers why are used to certain structures adopted from old school Senior developers, and those solutions works and are running in production today without any issues.

The problems come when these architectures have to be refactored to fit the latest tech or the solution is growing in size and complexity, and the development lifecycle for simple changes becomes big sprints on their own.

A traditional layered/onion/clean architecture is monolithic in its approach, and to see more information on this topic, I found the following article very interesting: https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html

There is a great article on Clean Architecture and how to implement it with Express.js or Typescript: https://medium.com/profusion-engineering/clean-architecture-a-practical-approach-cfc86ceac994

An in depth explanation about the Onion Architecture can be found on this page: https://medium.com/expedia-group-tech/onion-architecture-deed8a554423

I have shortly discussed where these architectures might be of use:

Clean Architecture

Onion Architecture

Vertical Slice Architecture

The big question still remains: Which one is better?

The answer is, it depends.... There is not a shoe that excels when doing hiking, running and cycling. Each type of shoe is made to fit a specific purpose.

One thing that comes to mind is when dealing with CQRS (Command and Query Responsibility Segregation) - a pattern that separates read and update operations for a specific data store. If you implement CQRS in your solution, you can maximize its performance, scalability and security.

What is Vertical Slice Architecture?

I first heard about Vertical Slice Architecture from Jimmy Bogard. He’s also the creator of some popular open-source libraries like MediatR and Automapper.

In his opinion, "the old Domain Logic patterns from the Patterns of Enterprise Architecture book no longer need to be an application-wide choice. Instead, we can start simple (Transaction Script) and simply refactor to the patterns that emerges from code smells we see in the business logic. New features only add code, you're not changing shared code and worrying about side effects. Very liberating!

There are some downsides to this approach, however, as it does assume that your team understands code smells and refactoring. If your team does not understand when a "service" is doing too much to push logic to the domain, this pattern is likely not for you.

If your team does understand refactoring, and can recognize when to push complex logic into the domain, into what DDD services should have been, and is familiar other Fowler/Kerievsky refactoring techniques, you'll find this style of architecture able to scale far past the traditional layered/concentric architectures."

As explained by this seasoned software architect, called Milan Jovanovic he bevies the following: "Vertical Slice Architecture was born from the pain of working with layered architectures. They force you to make changes in many different layers to implement a feature.

Let’s imagine what adding a new feature looks like in a layered architecture:

• Updating the domain model
• Modifying validation logic
• Creating a use case with MediatR
• Exposing an API endpoint from a controller

The cohesion is low because you are creating many files in different layers."

He dives deep into this with some example in a great video called Vertical Slice Architecture Setup From Scratch

He also has some great videos on how to code using Clean Architecture and also compares it to the Onion Architecture

Sine allot of solutions is heading towards SAAS, you should familiarize yourself with the Vertical Slice Architecture, as it could seriously streamline and fast pace you future development.