Thanks, Kyle! 🙏🏼

Absolutely true. However dependency it is about types and not real world functionality. So when you have type(interface) in app layer and dependent type(implementation of interface) at infrastructure layer that means that infrastructure dependent from app even if real world fact that app layer calls infrastructure layer. Intermediate project here is really about a way of abstracting types away from each other. So they may just sit on different namespaces to get there but more often they separated with projects. All of this can be implemented with 3tier layer architecture with proper IoC and have same good abstraction level. The thing here that ages ago when 3tier was popular DI technique wasn't so popular and references between layers were more strict so 3tier become a synonym of hard coupled architecture.

Not that complicated, you're just confusing term "depends" a bit. There is a source code dependency (having "using" of some class in other class) and flow of control dependency (calling stuff from one assembly in other). And while domain clearly depends on infrastructure on flow of control level, but you can avoid source code dependency by using interfaces and inversion of control. And that will make your app more mantanable, because changes in infrastructure would not affect your domain assemblies.

I'm also having a really hard time understand these concepts. I dont know whats different from calling the database directly from the controller. This has been done through all my university courses and every single youtube tutorial out there and even the laravel documentation. And now WHAT!? Its wrong to write logic in the controllers!?? I really have no idea how everything flipped like that it's either the world is trolling me or i really have no idea about software engineering (im a final year student)

@@charss5416 Basically we can access classes from different namespaces, in another folder, solution, or project. You can organize it any way you want. Tutorials and university courses as well as the official documentation usually use simple examples, the most straightforward way. In the real world they get really large projects. One of the reasons clean architecture is used, is so that it's easier to maintain large projects, So if for example you have to migrate from using SQL Server to another database like PostgreSQL, all you have to change is the infrastructure layer.

The way I look at it, it’s just layered architecture + dependency injection, so nothing new. I’m not sure if they’re just using that confusing diagram and the term “clean architecture” as gimmick to sell their course

Clean architecture and microservices aren't mutually exclusive. You can still apply clean architecture principles in microservices. In fact, with each service being scoped and small, it's easier to implement clean architecture and make it, well... cleaner. As to your first point, I think that it's the opposite but it's difficult to prove negative. Once you have clean architecture, it seems like you don't gain much from it. But it's when you don't have you realise how much you could benefit from it. I have a live example of it in my current work, where we have two systems developed in parallel, with only one conforming fully to the clean architecture principles. The one where we don't use it is a perfect example of the broken window theory.

@@ernest1520 I think his point was that there's no benefit of using clean architecture over N-Tier because the scope is small with a microservice and will probably stay that way until EOL.

Yeah, It’s wrong to blindly apply clean architecture to any project. But there are many projects that are a mess since they don’t have a clear boundary between data access logic and business logic. This is especially painful during migration from a monolith to microservices, refactoring, adding features or updating business logic

@@amantinband I get what you saying, but that's not necessarily down to N-Tier architecture for example. You can still apply SOLID principles in N-Tier... legacy projects typically had 3 tiers, where your domain talked directly to the database (infrastructure)... for example you can add a repositories layer in between with interfaces abstraction and you can still replace your infrastructure layers without impacting domain. But my point here was mainly about the fact that the whole concept of microservices is that they are smaller chunks of code with very clear domain boundaries and scopes, and when you have to either change those boundaries and scopes or the underlying infrastructure what you most often see is that teams build an entire new microservice and slowly deprecate the old one. Therefore I'm of the opinion that for the vast majority of businesses that do not have the resources to deal with the overhead of a more complex code architecture, N-Tier is perfectly fine as long as you do it right 😊

@@teekwick Yes, I got his point. However, my point was that clean architecture is in many cases applicable to microservices just like it is to other types of architecture. Do note that I said "in many cases", so of course there will be cases where the microservices are truly so "micro" that introducing clean architecture would be an overkill. Nevertheless, some core principles of clean architecture apply uniformly regardless the size, just like- for example- some principles of DDD can be used in various system, not necessarily conforming to the "full DDD".

I actually do exactly that in detail in my DDD course on dometrain. Did you check it out?

@@amantinband Yes, I tried in your youtube channel but it was confusing and I lost the sequence of video at some point. So I just hope that If I could get the whole journey in a single session than I would be able to understand all. Clean Architecture, DDD everything sounds so confusing to me.

Presentify. Notice it’s only available for MacOS though

Presentify but notice that it's available only on MacOS

I really don't like that almost every explanation of this design (on YT) is silently skipping important part(s). He even stated this question ~@5:09 and never explained. Point is that, graph is wrong. There is dependency between presentation and integration layers. So you can register concrete classes for dependency injection. And domain layer can't communicate with db, only application layer can. All in all, clean arch is almost same as n-tier. Only difference is moving db models (from data) and domain specific logic (from business) into new layer called domain. Only things left are either db specific, and moved to infrastructure or just following process steps, left in application layer.

They wont reference themselves. Since the infra layer reference to application layer it implements the abstractions of ifra layer methods in the applicstion layer (or the domain layer) and the application layer does the database interaction by using that ifra layer abstractions. The approach is every layer has its own abstractions that implemented in the infra layer about the database interactions, and when something needed from the database, these infra interfaces will be used. By that way, you try to achieve separation of concerns

Yeah not sure how that happened! Should be fixed now 🙂

Hey Adrian. The implementation of web clients sit in the infrastructure layer. Your domain, by definition, cannot sit in an external API. I would recommend taking a look at some open source projects that are structured following clean architecture, I think it will give you some clarity around this 🙂

Diagrams - figma. Slides - obsidian

You are the greatest for replying! ❤️

The 2 clean architecture courses cover everything from the basics to microservices, error handling, testing, authorization etc' on a different app all together

That’s a great topic that I really like discussing and I cover thoroughly in my DDD course. If the logic is simply orchestrating domain objects then it belongs in the application layer. If the logic is business logic/decision then the short answer is: Passing a repository to a domain object and having it fetch another domain object is called a “disconnected domain model”. This is a form of lazy loading and is usually a sign that the domain isn’t modeled correctly. The alternatives are: 1. Introducing a domain object or updating the current design so that all data needed to make the business decision are part of the domain object. 2. Encapsulating the logic in a domain service. The domain service will fetch data from dependencies and orchestrate the domain objects.

That’s incorrect. It’s actually quite common to place repository interfaces on the domain layer. There are similarities between layered and clean architecture but there are also many differences and nuances

@@amantinband How would it sound correct (in case of repository)?

My course is part of the dometrain platform so I don't control prices/discounts etc'

There are various approaches for designing a RESTful API. I like looking at it like folders where the route is the path to a file. Does that make sense?

Might seem like that but having a separate domain layer is a world of difference, see 3:01

Separation of concerns, and business cases (Application) tend change more frequently than the underlying concept/model (Domain).

Thanks for the feedback. Never occurred to me it may be distracting

100% agree. But I like to have a data interface in application layer and then implement it in a separate project. This is how I can control and nobody will use some framework everywhere in application.

Exactly people don't understand SOLID principles and design patterns and then complain about OOPs....

Between sentences? Or as part of the sentence? Would you have preferred a cut there or for me to pause for less time? Lmk so I can improve 🫶🏼