The Problem with Clean Architecture: Vertical Slices

Published in

Design Microservices Architecture with Patterns & Principles

6 min readFeb 15, 2023

In this article, we are going to learn the Problem with Clean Architecture which is Vertical Slices.

While Clean Architecture provides many benefits for software development, there are also some potential drawbacks to consider. Vertical business logic implementation codes required to modify all layers: i.e. add to basket, checkout order use cases. So we have to touch on every layers even we develop basic use cases.

I have just published a new course — Design Microservices Architecture with Patterns & Principles.

Introduction — Clean Architecture

In the previous articles, we have learned Clean Architecture with Dependency Rule and Design Clean Architecture for E-Commerce Application. You can follow from articles below:

After that we realize some pain points of Clean Architecture implementation that makes harder to continue develop new features into codebase.

Design: Clean Architecture— Horizontal Scaling — E-Commerce App

Before start, let’s remember how we can design our e-commerce application with Clean Architecture and scale horizontally using Load Balancer:

Now our application getting more request from different channels like mobile app, web browser so on. That means we need to managed Increase of Concurrent User. For that purpose we have added horizontal scaling application servers And put the Load balancer on front of our application.
Load Balancer will accommodate the request and send request to our e commerce application servers with using consistent hashing algorithms. This will provide to load equally for the servers.

Evaluate: Clean Architecture

If we evaluate the current Clean Architecture for E-Commerce Application, you can see the Benefits and Drawbacks at below :

In previous article, we focus on Scalability problems. Now we can handle good amount of request with helping from horizontal scale and load balancer. So now we can focus on the main problems of Clean Architecture which's are

Layers are independent but those are technical layers:
Domain, Infrastructure, Application and UI Layer
Vertical business logic implementation codes required to modify all layers: i.e. add to basket, checkout order use cases

Pain Points of Clean Architecture

You can see the image at below, The typical structure is to create projects or libraries that deal with:

UI layer
Application layer
Domain layer
Infrastructure layer

Here you can see the pain points of using Clean Architecture:

Context Switching

For example, when we were working on a feature and needed to work on any combination of data access, domain or application logic, we had to switch contexts into a different software project.

These are totally different folder structure and we had to remember and re-visit codes from other folder and continue with totally different code base. This is not efficiency when it comes to developing a new feature. So the folder structure requires DDD-bounded contexts approaches that we can manage scope for business features.

Vertical Slice Architecture

Vertical Slice Architecture introduces by Jimmy Bogard and it offers this architecture against to traditional layered/onion/clean architecture approaches.

When we are designing application with Layered and Clean architecture, the idea is to provide loose coupling and high cohesion. But with providing loosely coupling layers, this time we face that highly coupling vertical slices when developing any feature into our software.

Vertical Slice architecture aims to organize code around specific features or use cases, rather than technical concerns. In a Vertical Slice architecture, a feature is implemented across all layers of the software, from the user interface to the database. This approach is often used in the development of complex, feature-rich applications, particularly those that are delivered over the web.

The idea behind Vertical Slice architecture is that instead of creating separate layers of code for each technical concern, such as user interface, data access, and business logic, the code is organized around a particular feature or use case. This means that all the code related to a feature is contained in one place, making it easier to understand, test, and modify.

So that means when adding or changing a feature in an application, we are typically developing into almost all layers in the application code. We are changing the user interface, adding new Use Case classes into Application Layer, adding fields to models, modifying Data Access Codes, and so on. So that means we are highly couple with vertically slice when developing features. You can see the image at above, adding new feature requires to touch all layers that is a pain point of clean architecture.

For example, when building an e-commerce application. Instead of separating out the code for product listings, shopping cart functionality, and checkout into different layers, each feature would be implemented as a vertical slice that includes code for the user interface, the business logic, and the data access. This allows for a more cohesive implementation of each feature, as well as easier maintenance and scalability of the codebase.

Problem: Agility of New Features, Split Agile Teams

When we design our project with Clean Architecture, we reach the problem that is lack of Agility of New Features and Splitting Agile Teams.

Problems listed at above picture, main problems are Context Switching and Vertical Slices problems on Clean Architecture. When adding or changing a feature in an application, we are typically developing into almost all layers in the application code.

How can we solve this problem ?

And the solution is Modular Monolithic Architecture.

Design Modular Monolithic Architecture — E-Commerce App

If we design e-commerce application with Modular Monolithic architecture, you can see the image below:

According to architecture, we can encapsulate new feature developments into a module. And every module can implement its own architecture like Layered, Onion, Clean and so on.

Design Microservice Architecture — E-Commerce App

If we design e-commerce application with Microservice architecture, you can see the image below:

Product microservice can use NoSQL document database Shopping Cart microservice can use NoSQL key-value pair database and Order microservice can use Relational database as per microservice data storage requirements.

What’s Next ?

Step by Step Design Architectures w/ Course