Understand Clean Architecture in 7 Minutes

In today's video, we'll do a quick overview of clean architecture, one of the most common architectural patterns for how to structure software.

Connect with me on 'em socials:

[kmcdo]

congrats on course #2 on dometrain! I really enjoy the way you approach your educational content!

[bartoszcwiakala]

Hi,
I watched a number of videos on the topic and I had questions after each. This video was fantastic and clarified all the questions I had in the previous videos.

Thank you!!

[Luismvm]

Just my thoughts, as much as I like how clean architecture keeps everything tidy and overall a more flexible way to architect your code, after 14 years of software development in large corporate projects, startups and freelancing consulting... I can count on one hand the times I've seen anyone benefiting from that flexibility.
The more we move into smaller microservices, the less value you get out of it. Project changes that require infrastructure changes, often come with other larger changes in the tech stack as well. You often endup needing to rebuild the microservice anyway.
I know everyone slags off N-Tier architecture, but for the vast majority of cases it's still the simplest and most efficient way of structuring your code and has a much lower barrier of entry which largely benefits smaller companies.

As with any technology always choose what fits better with your team and your business, even if it's not the more "correct" way of doing things.

[alexandroszountas]

Already took your 3 courses. Waiting for DDD deep dive. Congratulations on your excellent work!

[grant]

Been following your older clean architecture videos before i start my new role and theyve been an amazing help. Architectures can sometimes feel a bit convoluted but you make it easy to follow. Will defo check out your new course in future

[Myuuiii]

Literally learning clean architecture right now, this’ll be helpful xD

[MSYT]

Very well explained with visual slides!

[rlarno]

@amantinband why do you not use and demo TDD in your course? For me the main reason for using a 'clean' architecture is because you actually get to have fully testable domain and application logic layers. The main guardrail that will keep your product agile and alive.
At a minimum it should be mentioned.

[stewieshka]

Will you record a video about migration to minimal api from controllers?

[trevorwilson]

I’m really struggling to see how clean architecture is really that different from a layered approach. Maybe there’s an additional layer for domain/entities and another level of indirection. Honestly, drawing architecture using concentric circles and with dependencies upside down just makes the architecture look really different when it’s not that different to layered architecture. The idea that infrastructure is dependent on application logic makes no sense. It’s clearly application logic depends on infrastructure. Just because the arrow is in the wrong direction and there is some intermediate project doesn’t change that. Even if there’s an interface layer that mediates between the application logic and the infrastructure doesn’t change the fact that the application logic layer depends on the infrastructure. Don’t get me wrong I like Uncle bob, but this is just really unclear and confusing. It’s a solution looking for a problem.

[pdhar]

Impressive !!! short and to the point.

[chriserony]

Hi! Thank you so much! Junior dev and I had learned about Service/Controller/Repository(DAO)/Models, but wasn't sure where all the nuanced extra classes would go. Like those Request & Response objects (Glad to see they go in Controller/Presentation layer!)

Where would you put mappers for the domain objects? Would that be in the Repository layer?

What about objects for request bodies that aren't domains? Like if I was going to fetch from the DB the settings of a user who belonged to a group. I might have to span multiple tables & it wouldn't fit into just a clean "users" or "settings" object. Where should I put that object?

[khyr-hlyt]

Thank you. It was explained in the easiest way

[big]

Thank you very much, for your teaching.

[bedirhandincer]

I noticed that some are putting the interfaces for the repository in the domain layer and others in the application layer. What is the correct way?

[RaviKumar-kdnh]

Thank you very much. Excellent explanation.

[dfytq]

Thanks a lot. You described it so well that I could understand it in first try. One request, Please make a long video where you will cover Breakdown the problem description, identify domains, repositories, Entities, settingup a clean architecture project. Thank you.

[dinhdotdev]

Just group Application layer and Domain layer into one and call it "Business Logic" layer, then add an abstraction like a repository pattern between Business Logic and Data Access Layer and you will have the same "architecture"

[ademirj]

Isn't it correct for the domain layer to have repository interfaces instead of the application layer? The domain services could have behavirous that interact with database by repository interface?

[ronaldabellano]

The problem with that is, is it okay for the infrastructure layer to point towards the domain layer? How can the DbContext from infrastructure layer travel to Domain layer?