I've been looking into how to implement "clean architecture" in my projects. I like the idea of it but I've found it hard to visualise it. The exam...
For further actions, you may consider blocking this person and/or reporting abuse
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.
@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.
I have a project coming up that will need to be easily maintainable which is where the curiosity comes in. But I will try to dive in with "baby steps" and introduce the principles into other projects to prepare for the project I mentioned. Thanks for the input :D