Lead Product Evangelist @Kentico, Founding partner @craftbrewingbiz. love to learn / teach web dev & software engineering, collecting vinyl records, mowing my lawn, craft 🍺
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.
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.
Thank you for the very detailed explanation! It actually helped a lot! I'll have a look at those resources as well, but this explanation has already made things click a bit more.
Lead Product Evangelist @Kentico, Founding partner @craftbrewingbiz. love to learn / teach web dev & software engineering, collecting vinyl records, mowing my lawn, craft 🍺
I've used Clean Architecture in a couple apps and it's proven to be a valuable pattern for developing scalable, consistent, and composable architectures.
I've also built many apps that didn't need the complexity of Clean Architecture (often because they were simple or very CRUD focused) and I don't feel it was wrong to not use it there.
I think following SOLID design principles leads to something like Clean Architecture - so it's not going to be a bad choice, for your requirements, even if it is the wrong choice.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Pros & Cons
Pros:
Cons:
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.
Thank you for the very detailed explanation! It actually helped a lot! I'll have a look at those resources as well, but this explanation has already made things click a bit more.
Welcome!
I've used Clean Architecture in a couple apps and it's proven to be a valuable pattern for developing scalable, consistent, and composable architectures.
I've also built many apps that didn't need the complexity of Clean Architecture (often because they were simple or very CRUD focused) and I don't feel it was wrong to not use it there.
I think following SOLID design principles leads to something like Clean Architecture - so it's not going to be a bad choice, for your requirements, even if it is the wrong choice.