Hi Dan. Let me just say I appreciate you not editing out the hiccups and mistakes made. Really adds to the authenticity of the video. Explanations are succinct. Keep up the great content!
I have seen other clean architecture structures, which are definitely overkilling for small and mid-size applications. Imho, this structure explains the very basics of clean architecture without being lost with too many projects and folders. The next step for me would be how the folder structure could vary as the applications become complex. To which layer validators, helpers/extensions, exception handlers, shared code, cache logic, externals API calls, and aggregations go. It would be great to have a video on those lines.
Just BRILLIANT! BEST 45 minutes I have spent! Yes, I implemented Adralis spec and completely got lost midway and finally implemented an abridged version of it. Thanks a lot for this video. Also, do you have any videos that explain the specification/filters and repo marriage of the Clean arch? Thanks
Thank you for sharing your thoughts with us. Now it looks a bit more clear for me as to what is this clean architecture is. But I wonder if it is really something which is used commonly in real life…
it mostly boils down to where you define the interfaces and how you name your projects. By the way, I would love to see a tutorial from you about combining any of onion/clean/hexagonal architecture with "vertical slices". Derek Comartin from CodeOpinion RU-vid channel talks about this but I do not understand how it might be applied to a project, which I believe you can explain very clearly...
I already have a video on vertical slices. I am not a big supporter of Derek's approach and we had a lot of discussions about it. Still, I don't think an approach where you put everything in one place only for the sake of functional cohesion is scalable in real projects. Here is my approach to vertical slices: ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-DbT7SLxHzfs.html
Awesome video prepared, The way you explained the clean architecture is just superb, Finally I will say this kind of video is not available on you tube, you have done superb work. Thank You
I wonder how to deal the API project when is not a UI layer but a "repository" layer (eg. when a UI like blazor wasm use it as a source of data); the API obviously should use the application/service and not directly the repository to get the data from db, but the Blazor Wasm should call directly the api (with httpclient) or it is better to have "another" application/service layer that expose List grabbed from the api ?
When you are using Blazor WASM, always try to think that you are using Angular or React. It's a regular SPA. This means that the only way you should communicate between your WASM front end and your back end is through an API.
@@Codewrinkles Thank you Dan. Another big doubt is if the implementation of the ISomethingService (eg. simple services that don't have business rules but only expose the data like return _repository.ListAsync() ) goes in Application layer or in another (called what? Service?). Someone like Nick Chapsas says that in Application project there shouldn't be ANY implementation.
I'm not sure I agree with the final part. In the The application layer is implementation at its heart. its main reason to exist is to make the application working, implement application flows and so on. Though, I agree you usually should not implement an interface in the same layer you declare it. One approach would be to place all abstraction in a different project. But in my opinion, a layer is not defined by a project. It could very well include several projects. So even if you do that, you are still in the application layer. Another approach would be to not use interfaces, but then those service will be very hard to unit test.
Thank you so much. I just discovered your channel and saw 2-3 videos. Your videos are very straight forward and to the point. If I would like to add a UI (e.g. MVC application with razor pages) to this solution, is it cleaner to consume/edit data over the API or talk to the service? And where would you place DTOs or ViewModels here?
As usual great explanation but I have a question . Can I use the repository interface directly from the api or I have to use it in service only and then use service in the api
Domain here is more “static”, but there is concept called Domain Event that is more “dynamic”. Even there is an approach called Event Storming. Hard to decide if some thing belongs to User Case or Domain Event.
In real application it's very often to decide whether something belongs to the use cases or to the domain. Or to the domain events, which theoretically should also be part of the domain itself. That's why it comes also to creativity and understanding the business for which you do the application. And that's the reason why there is no exact recipe for the perfect software.
this pattern since share data access layer's entity as well presentation's layer models. But how about DAL entity is different to domain's models? DAL entity should refer to who? ORM should put in which project files?
Hello, I enjoyed this video and found it to be very informative. My follow up question is: can the Infrastructure layer be used the same as a DAL project would be used in your other videos? I.e. can DAL reside in Infra layer along with other services such as Scheduling and Mailing functionalities?
Well, from my point of view it's very simple: infrastructure = outside systems that my application needs to work with. Therefore, data access is for sure infrastructure, as the database management system is an outside system that my application integrates with. Now, for the more nuanced stuff. If you create just on project that logically represents the infrastructure layer, you will find out that sooner rather than later that project will get way to big, containing code that: integrates with DB (DAL), code that connects to external API, code that connects to Azure services and so on. To avoid this, in real projects I usually start by having at least two different VS projects that logically represent my infrastructure layer (a layer != one project. Could be more): a data access project (usuall called {Project}.Infrastructure.Dal) and a general purpose infrastructure project: {Project}. Infrastructure. And if for instance i see that at a certain point I have a lot of code that, for instance, represents Azure Function, I move it out to another infrastructure project called {Project}.Infrastructure.AzureFunctions. I hope it makes sense and helps clarifying your question.
Hi very nice explanation of such a confusing concept I am still some how confused , you went through layers of abstractions and still inside the controller we rely on the core project because we need to pass the entity(weatherforecast) am I missing something??!!
It would be nice to see a video on how does this architecture, with all of it's abastractions, actually helps us for example in unit testing, mocking, maintaing code etc. For me that part is still something i can't understand.
The main reason for all of the things you mentioned is that clean architecture decouples the different layer using these abstractions. This means in turn that each layer can be tested, maintained in isolation of all the other layers. In a nutshell, it's the dependency inversion principle from the SOLID paradigm.
@@Codewrinkles I understood the theory, i'ts just hard to find videos with examples on how to do the things i mentioned in original comment with this kind of architecture approach. so that's why i just wrote the comment as an idea for the video. im sure that whenever we see something in action, and then try it ourselves that it actually becomes clear.
This is actually a very long and complicated discussion. Main point is that the models you put in your domain (core) layer are your domain classes. Not EF classes. Since we have EF and code first, in most cases it's more convenient to just reuse the same domain models to base your db schema upon. That would work fine in most of the applications. In most complex scenarios, you might want to have indeed dedicated EF models in the DAL/infrastructure layer and use a mapper to map them to domain entities. Traditionally, those classes that represent the database were called data access objects (DAOs) but these are long forgotten in the .NET world and on the verge to be forgotten even in the Java ecosystem.
Thank you so much! Very useful tutorials! My question is why to place interfaces into Application layer? Interfaces seem to be part of domain logic (even repository interface) and should go to Core. Doing this will also remove Infrastructure dependency on the Application layer. Seems to be a cleaner approach. Or am I missing something?
Well, interfaces should be defined by the client (the party who needs it) otherwise there's no dependency inversion whatsoever. And that the primary reason why we are using interfaces in Asp.Net Core. I have 3 different videos that will give you some concrete answers to this and I'd suggest you going through them in this order: 1. Dependency inversion principle made easy: ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-CQShvMDBCso.html 2. Building an IoC (to better understand dependency inversion): ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-GZ7MYupyOlY.html 3. NLayer vs Clean architecture (this will provide the final answer to your question): ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-0JRI-xq10yo.html
@@Codewrinkles I have watched videos! Very helpful! Thank you! Still slightly confused. It is easier for me to look at the purpose of my application(defined by business rules) as the actual client(as you say - the party who needs it). Interfaces define what application needs (or does), so I place it with other things that define/explain the domain of my application, such as abstractions, entities, events, exceptions, rules, validations, etc. All goes into Core layer project(s). That layer has no dependencies. Application and Infrastructure layers reference Core layer to implement interfaces, without a need to reference each other. As you mention in your video, the Application layer might contain multiple projects. For example, if an application needs a third party library to work with PDF, and also needs to connect to some vendor using web services - both implementations would be in the Application layer but I would create two different projects for each, to keep it clean. So having multiple projects in the Application layer, and assuming each of those projects needs the same repository, where would you define that repository interface? You need some common place where both projects from Application layer and Infrastructure project (that implements the interface) can reference it. I assume you can place a repository interface in one of the Application layer projects and reference it from the other project in the Application layer (and also from the Infrastructure project that implements the repository) but it seems messy. Core layer looks the perfect common place for repository, and other interfaces. I am sorry for the long post. But I really want to understand it and I do appreciate your responses very much.
@@lvovskym I think you are overthinking the "client part". Here, there are really no middle grounds. In which layer do you use the interfaces? In the application. It means that the application is the layer that should define what interfaces are needed and what they should contain. If you define your interfaces in "Core" then the "Core" should also use them to perform work. That's just simple dependency inversion principle.....
@@lvovskym For the second part of your comment, you'd just extract to a Application.Common project all the interfaces that belong to the application layer.
@@Codewrinkles I would disagree that I am overthinking the "client part". Conceptually, at least for me, it is much easier to think about an application that is being created as the party who needs it. Core layer in this case defines not only entities/rules/etc. but also the behavior of the application by defining interfaces. And all implementations (or actual work) happen in the Application layer, and follows the needs of the app. Also, I think projects in the Application layer should not reference each other (or Application.Common) All work in this layer (as in outer-most layer) is done through abstractions defined in Core. In your first video(Dependency inversion principle made easy) listed above you clearly say that your app defines the ILogger interface, and CwkLogger project implements it. For a larger application, you would move ILogger interface to the Core layer and CwkLogger project would be part of the Application layer. Following this pattern, all interfaces should be in the Core layer. And assuming that your app owns the database, it should also have a repository interface in the Core layer to define how data should be handled by Infrastructure and Application layer projects when implementing access or working with data. Anyway, I do understand "there are really no middle grounds" on how things can be done, but I do struggle to understand why putting interfaces, that define application needs, into the Core layer - breaks the Dependency inversion principle. Especially after re-watching your video, I would think that such approach is the cleanest implementation of Dependency inversion principle :) I DO appreciate your responses very much! it makes my brain work hard. I also go over your other videos and find them very useful! Thank you very much!
The answer is always "it depends". If we want to be purists, then each layer should come with its own models. And this would mean that we'd need to use DTOs for transfering data from one layer to another. But I have a video only dediacated to DTOs: ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-Yw9ZP9KYESo.html
