DEV Community

adro.codes
adro.codes

Posted on

Clean architecture - Your approach

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 examples I am looking at are simple "Counter" apps (using React with Typescript) and the setup seems overkill. The approach will obviously become more and more beneficial as the project grows.

The Question

I'd like to hear from other developers;

  • Who has experience using clean architecture practices. What are the pros and cons?
  • What was your "aha" moment, when everything started making sense?
  • What resources did you use to help you learn the fundamentals of clean architecture?
  • How would you explain it to a 5-year-old?

Top comments (5)

Collapse
 
seangwright profile image
Sean G. Wright • Edited

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.

Collapse
 
hurricaneinteractive profile image
adro.codes

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.

Collapse
 
seangwright profile image
Sean G. Wright

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.

Collapse
 
skydevht profile image
Holy-Elie Scaïde

@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.

Collapse
 
hurricaneinteractive profile image
adro.codes

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