How to structure a clean architecture Asp.Net Core app

  Рет қаралды 23,419

Codewrinkles

Codewrinkles

Күн бұрын

Пікірлер: 56
@venkateshk2732
@venkateshk2732 2 жыл бұрын
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.
@ShadySoul07
@ShadySoul07 Жыл бұрын
Agreed 💯
@Carvahlio
@Carvahlio Жыл бұрын
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!
@Codewrinkles
@Codewrinkles Жыл бұрын
I appreciate that!
@avecesar
@avecesar 2 жыл бұрын
Thank you for sharing. It is nice how you get to contextualize the advantages and disadvantages of this approach.
@Codewrinkles
@Codewrinkles 2 жыл бұрын
Glad it was helpful!
@Ram92026z
@Ram92026z Жыл бұрын
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
@torrvic1156
@torrvic1156 Жыл бұрын
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…
@alpsavasdev
@alpsavasdev Жыл бұрын
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 KZbin 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...
@Codewrinkles
@Codewrinkles Жыл бұрын
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: kzbin.info/www/bejne/epO3aIaCra2tnNU
@alpsavasdev
@alpsavasdev Жыл бұрын
@@Codewrinkles Yeah, I just saw right after writing this comment. I am definitely goning to watch it. Thanks a lot!
@sandroriz
@sandroriz 2 жыл бұрын
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 ?
@Codewrinkles
@Codewrinkles 2 жыл бұрын
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.
@sandroriz
@sandroriz 2 жыл бұрын
@@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.
@Codewrinkles
@Codewrinkles 2 жыл бұрын
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.
@nirajjoshi3349
@nirajjoshi3349 2 жыл бұрын
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
@kajmaring3333
@kajmaring3333 2 жыл бұрын
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?
@jxndwl
@jxndwl 2 жыл бұрын
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.
@Codewrinkles
@Codewrinkles 2 жыл бұрын
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.
@talkathiriify
@talkathiriify 2 жыл бұрын
Excellent structure. Thank you very much.
@Codewrinkles
@Codewrinkles 2 жыл бұрын
Glad you liked it!
@ibrahimghazy4242
@ibrahimghazy4242 Жыл бұрын
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
@mikhailvasyutyk6770
@mikhailvasyutyk6770 Жыл бұрын
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?
@Codewrinkles
@Codewrinkles Жыл бұрын
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.
@mikhailvasyutyk6770
@mikhailvasyutyk6770 Жыл бұрын
@@Codewrinkles Yes, this clarified my question. Thank you!
@juankasem4911
@juankasem4911 2 жыл бұрын
Can you start a bank management system application implementing the Clean architecture and domain-driven design? It would be a great work!
@Codewrinkles
@Codewrinkles 2 жыл бұрын
Great suggestion! However, clean architecture principles are the same, no matter what type of apps you are building.
@nirajchandrajoshi
@nirajchandrajoshi 2 жыл бұрын
very good and informatic knowledge shared by you.
@afshin7104
@afshin7104 2 жыл бұрын
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??!!
@pauloperovic5683
@pauloperovic5683 2 жыл бұрын
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.
@Codewrinkles
@Codewrinkles 2 жыл бұрын
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.
@pauloperovic5683
@pauloperovic5683 2 жыл бұрын
@@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.
@Codewrinkles
@Codewrinkles 2 жыл бұрын
@@pauloperovic5683 OK, thank you very much for your feedback. I'll definitely try to create an easy understandable video on these topics.
@lvovskym
@lvovskym Жыл бұрын
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?
@Codewrinkles
@Codewrinkles Жыл бұрын
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: kzbin.info/www/bejne/eYK2mamDead2qdE 2. Building an IoC (to better understand dependency inversion): kzbin.info/www/bejne/fYuafoyrpd6Cors 3. NLayer vs Clean architecture (this will provide the final answer to your question): kzbin.info/www/bejne/Znu1emCuppZjr9E
@lvovskym
@lvovskym Жыл бұрын
@@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.
@Codewrinkles
@Codewrinkles Жыл бұрын
@@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.....
@Codewrinkles
@Codewrinkles Жыл бұрын
@@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.
@lvovskym
@lvovskym Жыл бұрын
@@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!
@yerharris5674
@yerharris5674 2 жыл бұрын
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?
@krishanthadharmasiri5266
@krishanthadharmasiri5266 Жыл бұрын
Thank you very much , a very useful one 🙏
@Codewrinkles
@Codewrinkles Жыл бұрын
You are welcome
@kmud7750
@kmud7750 Жыл бұрын
Amazing video, subscribed!!
@Codewrinkles
@Codewrinkles Жыл бұрын
I'm glad you liked it. Also check the other videos on the channel. I think some of them might be useful.
@jonathanmutala8179
@jonathanmutala8179 2 жыл бұрын
The best ❤
@techwithameer
@techwithameer 2 жыл бұрын
Did we need seperate dtos for trasfering data between layers?
@Codewrinkles
@Codewrinkles Жыл бұрын
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: kzbin.info/www/bejne/j6ici4NvgL54idE
@CarrigansGuitarClub
@CarrigansGuitarClub 2 жыл бұрын
Very nice - can i download the code?
@botyironcastle
@botyironcastle Жыл бұрын
this is not clean, this is technical layering
@Codewrinkles
@Codewrinkles Жыл бұрын
Lol, ok.
@vivekkaushik9508
@vivekkaushik9508 Жыл бұрын
1.75x
@smez2926
@smez2926 2 жыл бұрын
6:36 the structure looks like a dog
@Codewrinkles
@Codewrinkles 2 жыл бұрын
Drawing is certainly not my top skill, especially with a mouse :))
@semen083
@semen083 2 жыл бұрын
Models for EntityFramework should be in "Core" layer?
@Codewrinkles
@Codewrinkles 2 жыл бұрын
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.
Clean architecture with CQRS and MediatR in Asp.Net Core
42:24
Codewrinkles
Рет қаралды 16 М.
My Daughter's Dumplings Are Filled With Coins #funny #cute #comedy
00:18
Funny daughter's daily life
Рет қаралды 21 МЛН
pumpkins #shorts
00:39
Mr DegrEE
Рет қаралды 72 МЛН
Как подписать? 😂 #shorts
00:10
Денис Кукояка
Рет қаралды 8 МЛН
Why is Clean Architecture so Popular?
11:52
CodeOpinion
Рет қаралды 49 М.
Clean ASP.NET Core API using MediatR and CQRS | Setup
22:39
Nick Chapsas
Рет қаралды 323 М.
Clean Architecture with ASP.NET Core 3.0 • Jason Taylor • GOTO 2019
50:47
Building a .NET 6 API Using TDD
1:38:59
Wes Doyle
Рет қаралды 146 М.
Clean Architecture in .NET 7 | Intent Architect Webinar
1:24:01
Intent Architect
Рет қаралды 18 М.
ASP.NET Core 8 Web API in Clean architecture from scratch
2:12:25
Fullstack Dev
Рет қаралды 23 М.
How to NOT Marry MediatR in Clean Architecture
19:40
About Clean Code
Рет қаралды 5 М.
My Daughter's Dumplings Are Filled With Coins #funny #cute #comedy
00:18
Funny daughter's daily life
Рет қаралды 21 МЛН