Clean architecture - Your approach

Pros & Cons

Pros:

• Consistent business logic through the app
• Swappable data persistence, external systems integration, and presentation
• Enables carving out a vertical feature slice into a separate service (microservice, nanoservice/serverless) without much difficulty
• Promotes more testable design patterns (Core business logic tends to always be testable)

Cons:

• Requires more intentional design (you can't reference data persistence APIs directly in your business logic)
• Due to the business logic being agnostic of the outer layers you can loose optimizations in being closer to library features and implementations with the benefit of looser coupling
• Can be overkill when only a CRUD app is needed

Aha

The aha moment for me came when I realized Clean Architecture puts the business domain at the center, not as a layer between presentation and data access.

When business logic is a layer and not a core it is dependent on the data persistence, which tends to leak as an abstraction throughout your business logic.

This increases coupling between components and makes your application harder to maintain.

By making data persistence and presentation outer layers on a core of business logic, it's easier to build features as vertical slices that can have their requirements changed independently of each other.

Links

Steve Smith talks a lot about Clean Architecture and has given talks and written blogs covering the subject.

His technology choice is ASP.NET Core, but the topics and points he makes could apply to other languages and frameworks.

Here is a video series from a Twitch stream: youtube.com/watch?v=k8cZUW4MS3I

Here is a sample project on GitHub where he also explains some principles of the architecture : github.com/ardalis/CleanArchitecture

Clean Architecture could be thought of as a rename of Hexagonal Architecture : blog.ndepend.com/hexagonal-archite...

Or Ports and Adapters : codingcanvas.com/hexagonal-archite...

Searching for any of these names should bring up relevant discussions.

Explanation

Traditional N-Tier architecture put code and functionality into layers.

It's like people standing in a line all facing the same direction.

The end of the line is the presentation layer where the design and interaction is.

The beginning of the line is data persistence.

Whoever a person can see is what they have dependencies on.

The person at the end of the line can see everyone in front of them - this is the presentation layer and it depends on everything.

The problem is that the business logic layer is in the middle of the line, which is good because it doesn't depend on the presentation layer (it can't see it), but it still depends on data persistence and external API connections, and anything else in front of it in the line.

The idea of Clean Architecture is, instead of making it a line, make it an onion where the center is the business logic and the layers around it take dependencies on it, but it doesn't take dependencies on anything else.

In a modern cloud environment where your application might integrate with different services, data storage, ect... over time, changing those things out doesn't require changing the business logic.

These external services live behind interfaces or adapters and can be swapped out easily as long as they fulfill the contract that the business logic depends on.

@seangwright has given a really extensive answer. Most of the time you would not need it. Being clean requires a lot of abstractions and boilerplate code to write all those contracts between the layers. I have used it in android app, but the codebase grew a lot. It was easily maintainable due to being clean, but I was the sole developer and opted out for a simpler MVP architecture. I think it's great if you're writing a business application that should be maintainable for a decade or so with various developers. It's the safest bet. But for a simpler app, it's overkill.
You should try to really understand it. I'm still following the outlined principles, like reducing your dependencies' surface area, bundle your business logic together,... Even if the architecture is not as clean. But the goal of designing software is not cleanliness but maintainability.