Clean Architecture with ASP.NET Core 8 | .NET Conf 2023
Vložit
- čas přidán 12. 05. 2024
- Clean Architecture (aka Onion, Hexagonal, Ports-and-Adapters) organizes your code in a way that limits its dependencies on infrastructure concerns. This results in much more testable, maintainable code and is ideal for Domain-Driven Design as well as microservices. Learn how to apply it to your ASP.NET Core apps!
Chapters:
00:00 Let's get started
00:06 What is Clean Architecture
01:25 When to use Clean Architecture
03:25 Two approaches to layered architecture
05:57 Demo
www.nuget.org/packages/Ardali...
07:25 Clean Architecture Rules
08:51 What belongs in the Core project
13:48 Demo
16:23 What about CQRS
16:45 What belongs in teh Use Cases project
17:01 Demo
18:35 What belongs in the Infrastructure project
20:02 Demo
21:29 What belongs in the Web project
22:05 Demo
23:57 The Shared Kernel
24:17 Demo
25:52 Resources
25:57 Q&A
Clean Architecture Template
github.com/ardalis/CleanArchi...
eShopOnWeb Reference Application
github.com/dotnet-architectur...
Architect Modern Apps w/ASP.NET Core eBook
dotnet.microsoft.com/learn/we...
More from Steve
ardalis.com
Download .NET 8 - aka.ms/get-dotnet-8
Hack Together - aka.ms/hacktogether/dotnet
Learn collection - aka.ms/learn-dotnet-8
.NET 8 Survey - aka.ms/dotnet-survey
Local Events - aka.ms/dotnetconf-local-event
Hero blog - aka.ms/dotnet8blog
Blog: aka.ms/dotnet/blog
Twitter: aka.ms/dotnet/twitter
TikTok: aka.ms/dotnet/tiktok
Mastodon: aka.ms/dotnet/mastodon
LinkedIn: aka.ms/dotnet/linkedin
Facebook: aka.ms/dotnet/facebook
Docs: learn.microsoft.com/dotnet
Forums: aka.ms/dotnet/forums
🙋♀️Q&A: aka.ms/dotnet-qa
👨🎓Microsoft Learn: aka.ms/learndotnet
#dotnet - Věda a technologie
Fantastic! God bless you!
Just want to say thank you for your very good explained clean architecture presentation! Hopefully you can extend this presentation in a more indepth series. I am sure to be checking out your template and play with it.
Great video Steve. Fantastic to see Microsoft finally talking about this, domains and DDD. Hopefully we'll see some domain-centric templates rather than those entrenching anti patterns like focus on the tech choice (MVC) and pushing teams towards procedural code (top level functions).
Amazing talk! Love it! Architecture is not an easy topic and you made it clear and approachable. I'll do a "donet new" to continue my exploration.
Great presentation Steve. Our agency had implemented something very similar in the past where we inverted the dependency between the business layer and the data access layer, so this seems like a logical progression for us. We're currently debating the virtues of a BFF layer too. I'm wondering if that will somehow factor into clean architecture in the future. The logic to combine data from multiple APIs needs to go somewhere after all.
Thanks, Ardalis for this amazing presentation, which made the CA very simple and easy to comprehend.
From my own perspective, I'd like to see those NuGet packages' code-base in the project, which will give them full control over them to maintain and adapt them based on the needs 👍
I don't see the clean in clean architecture. This looks like an awful huge amount of projects, files and folders for a ToDo App. The Point of seperating infrastructure and business logic seems not represented (EF Core was in the Business Layer, wasn't it?). The weird replacement for controllers with the ?reapr? framework looks just like a show off, what is the point of that? I don't see any advantage over simple API Controllers, in fact, the technique to place code that belongs to the controllers just in files nested by filename makes it unnecessarily scattered.
I was really looking forward to this, but it just left me confused and I still trust the n-tier architecture even more. I think now, any architecture is clean, as long as it is consistent and scales.
Pls change my mind 🙂
Even though many experts say that Clean architecture and Onion architecture are pretty much the same, their implementation of the two differs considerably. It is almost as if each of the architectures has their own "style", their own conventions in a way, which grow increasingly more complicated to the naked eye. But it doesn't have to be that way.
Let me give you a personal example - I've recently refactored a few apps from n-tier to Onion, and in essence it isn't much more than moving the database/cloud interfaces from the infrastructure layer to the domain layer, and just pointing the application/services layer towards the domain layer instead of to the infrastructure layer. Boom, Onion.
Now lets say I were to copy code from the service classes to cqrs-style command and query classes (which does involve a lot of boilerplate unfortunately), and then rather than inject them in the controller I implement mediatr to call them. Now everyone who looks at my solution would say "oh, that's Clean architecture". Even though the change itself is simply stylistical.
My point was that it doesn't need to be as complex as presented in this video. Are there benefits to that increased complexity? I dunno. Maybe testability, cause with cqrs you just test commands and queries and not have to use much brain power on what needs testing. Maybe future extensability, cause you can just add a new command/query instead of modifying your service class (which maybe you shouldn't do as it can violate the O in SOLID). Maybe also avoiding your service class becoming huge (but on the other hand you're get so many folders and files for cqrs). I'm just thinking out loud, I'm no expert.
I heard a really good NDC talk a few week ago about how the so called 'functional core imperative shell' concept fits in nicely with this I would go have a read as that has convinced me more! The idea is something like this really encourages you to keep IO operations at the very edges of your application, and this inherently means that every bit of business logic is pretty much gonna end up as functional programming style functions that are super easy to test
It was a good learning experience through this video. Keep it up.
Great presentation. One of my favorites from this year!
Best video to understand CQRS, Clean Architecture without any clutter.
Your channel is a treasure trove of knowledge. Thanks!
Love your template, I would argue that the biggest advantage of Clean Architecture aside from the dependency enforcements as you mentioned, is that you can easily swap out and configure the entire infrastructure layer. This can be extremely useful when you will have multiple clients/front ends. You can reuse the entire business logic and only create different implementations for the infrastructure layer. Most useful IMO for hosted Blazor WASM solutions although blazor itself still has a bit to go and can be frustrating to debug.
How often have you done this 😂😂
thanks for amazing presentation. Our team have ~10 micro-services on production with clean architecture.. and I personally don't recommend it.. The benefits of Clean Architecture are true, but not as big as we talk (for most case). However the downside of Clean Architecture are Bigger than we think.. Unfortunately not many peoples share the bad sides of Clean Architecture... My recommendation is Vertical Architecture. (If we could rewrite all our microservices again 😢)
Really great video. Learned a lot.
Love this topic. I can tell you’re rushing through some of this content though due to the short session time constraints. Would be great to have more time on these topics and the same goes for most of the other content too.
Sounds nice, but I just can't fathom what a project with many entities would look like. If this is the complexity of a TODO app using CA, I'd imagine it would become completely overwhelming with a more complex domain. Could argue that it becomes second nature once you've trained your eye to the architecture, but I find it hard to believe that this is feasible for large systems or large teams. Feels more like a 'blue skies' design; works well in a perfect world where everyone is extremely disciplined.
If anyone could point me to a large scale system that uses this architecture I'd love to see it.
I have pretty much the same view on this
It actually enforces its dependency rules, rather than simply relying on developers to remember to be disciplined. It's not new - hexagonal and ports-and-adapters and clean have been around for a couple of decades now.
Great! Very nice!
Wow, just wow 👏👏👏
excellent, great Job!
Steve is a gift for .net community
thanks so much. my project run ok..
Superb!
This is the best video yet on clean architecture
This is great! Thanks on ture. I have one question, as you show code that has 2 Aggregates but I am interested in how you gonna organize your domain if you have multiple bounded contexts(no microservices please)? Complexity starts there and managing infrastructure and also you need to make some encapsulation between bounded context.I like to use "Majestic Monolite" in this case and I am wondering how we can use your template in that way or do you have ideas to put together something like that in future?
This is where you'd start looking at a "modular monolith" approach, which yes I'm developing some content around. An alternative to microservices that allows for separation of contexts (and even teams) but without the overhead of managing a distributed application.
great to see Ardalis here, I knew him from his Pluralsight course
2
Nice!!
Good Job :)
Great stuff
Thank you for the insightful video! Your explanation of the concepts was excellent. I did notice a dependency on MediatR within both DeleteContributorService and ContributorDeletedHandler in your Core project. This raised a question for me regarding the Dependency Principle in Clean Architecture. Isn't it advisable to steer clear of third-party dependencies within the Core/Domain layer? I'm curious if implementing an Adapter pattern, defining interfaces in the Core and implementing them in the Infrastructure layer, could help maintain cleaner separation. Your thoughts on achieving this balance between design principles and practicality would be much appreciated!
I allow dependencies in Core (and SharedKernel) provided they don't impede unit testing or have dependencies on out of process things. So, basically if they're pure functions. MediatR and GuardClauses and FluentValidation and such all fit this and are often useful in the domain model.
Thanks for the answer, Ardalis.
Great job,
can i ask you what is the difference between clean architecture and onion architecture and when use any of both ?
Thank you for your help
They're essentially the same. Clean Architecture by the book includes some specific patterns but the focus on keeping dependencies out of your Core/Domain is the main point to follow.
I would like the see the requirements documentation that this application satisfies.
Should I bother seeing the other videos on Clean Architecture with ASP.NET Core 6 (and 7)" before this one, or can I just start here?
how should we link the client project here, like Angular application? I suppose a folder like Client to add to the Web solution?
I would super appreciate a dark background.
For those many with bad eyes
Hello, thanks for the presentation. Where we can access the source code?
You got it in video: 25:52 min.
@@MaxSupercarslink?
Has anyone looked into using the wolverine library instead of mediatr?
Probably trivial to swap out.
This if funny since I've never had any interest in "academic" analyses of different software models. I probably don't even know half the names of the modern models. And now, watching this video, it is funny to realize there are actually names for these things I've used for decades. For instance, I've never called anything in my code "aggregates" (except in SQL). There is just bunch of code in services-folder, or whatever, doing stuff to the data and outputting it in some coherent structure.
After watching this video, I probably don't remember what "aggregates" are tomorrow. And I don't think I even should because I've found that when you _don't_ follow paradigms to the letter, you have much more flexibility in your code. You just have to communicate (by code comments, documents, somehow) why you deviate from the normal flow here and there. Maybe you need to do something for performance reasons like sometimes I need to use non-normalized databases, which feels icky, but enhances performance a lot in certain situations.
But it watch good watching. I think I have to subscribe to this channel.
Clean architecture looks great until we do not touch an event-based communication that generated MediatR which is a very arguable approach to building software because many explicit things become implicit, code transparency (traceability) goes to zero, and the chaoticness of the solution is increased.
Separating business logic into a separate independent project is a good approach to organizing code in a large solution, but only with a traditional way of code communication with service and dependency injection.
imo - this is way more complex than it should be
That’s kind of the point. It’s not supposed to be for very simple applications
I need to create project from scratch in dotnet core 8.0 using entity framework..can i refer this folder structure??we will be creating apis
Doesn't your specifications have ef core references? Looks like that, with that Include-method
Looks like so, so is the "UseCases" layer for cqrs which is presented as sitting between the core layer and the infrastructure layer, which I find it weird.
@@nikogj9495 specifications belong to the domain/business (he makes no distinction) layer here and he must certainly have a ef core reference there, that is being dependent on infrastructure concerns.
Yes, commands and queries belong to the application layer, which sits between infrastructure and domain layer, but only if we are speaking in terms of "compile time dependencies". In runtime, the application layer will orchestrate between infrastructure and domain layers, through the repositories defined in the domain layer, but implemented in the infrastructure layer.
@@svorskemattias What I find weird is having a dependency to ef core on the domain layer.
I thought this core layer was supposed to be POCO and dependent on basically nothing else
@@nikogj9495 yes. Then we agree. This domain layer is coupled to infrastructural concerns.
@@nikogj9495 It would be weird if it were the case.
I know it might sound like a stupid question, but in all the clean architecture diagrams i've seen, there's never an arrow between UI and Infrastructure, and it makes me wonder if it's just to put emphasis on the fact that the dependencies are pointing to the core or is it because I don't understand something and the UI shouldn't reference the Infrastructure?
Yes the UI doesn't need to know about the infrastructure. All the UI should be interested in is data irrespective of the infrastructure. This decoupling of their dependency makes maintenance easy.
It's an optional compile-time dependency but a required runtime dependency. For simplicity I usually just include a project reference from UI to Infra but if you do it right you can avoid that and just copy the DLLs from Infra to Web/bin and load the assemblies with reflection at startup and be assured there are NO direct references within UI/Web to Infra types.
I can't imagine a single case where I would take a mediator for MVP, just as I can't imagine how I would live without Nlayer in terms of expansion and testing.
Why do we need this unnecessary complexity? To setup the events? This can also be done in the classic Nlayer. But we lose visibility and lose auto-click on references.
Perhaps this is another "wall" that needs to be overcome, as it was with DI at the time)
Tell me more about `IRepository`
Here's a whole presentation on the subject: czcams.com/video/g6cjCbxq54Y/video.html
Its an interface of an interface
Hello!
where is the Shared Kernel repository?
It has been converted into a NuGet package.
I like the idea of eliminating Swagger and Postman this makes remote code reviews clean...
Whats the difference to Jason Taylors Template?
I haven't looked recently enough to say with confidence.
Hi, why didn't you add subtitles to the film?
There are subtitles. You may need to press the CC button to enable subtitles/closed captions.
this works like aspire dotnet is that true?
No, I don't think it's really related.
hindsight is 20/20. If you know your domain then great, but software usually isn't built that way. Lots of great unknowns when designing the thing to it's final form
hi
AHHHHH, it`s so hard to understand this things... I have a project with clear architecture (my clear architecture, that 100 times easier, without commands and...) and want to rewrite it with something better. But this... really hard. I don`t understand...
That's why I created the solution template, so you have an easy starting point. (And so I didn't have to set it up every time for a new client's app).
This presentation/video needed to be about three hours longer. You're covering way too much, too quickly. I would appreciate much smaller demo and a much smaller project.
I also do workshops and online training which obviously goes into greater depth. This is meant to be a quick, dense overview that hopefully delivers something for everyone with minimal fluff.
I am so dissapointed when I see somebody coding like this 😂😂😂
Interesting concept but definitely overengineered. Later on, adding anything new will require a LOT of plumbing added to all the projects, and it will be redundant. Speak from experience building big systems.
The Clean Architecture chart needs more detail - it does not align with the presented list of projects in the template.
My immediate thought. I still see applications as N-Tier - it makes sense and about everything depending on the database - no it doesn't. You can use interfaces where needed for and use Mocks in your unit tests. Why do people always fall for the new shiny tool when it will be replaced in a couple years...?
Your queries/handlers and commands/handlers seem unnecessarily complicated. Why not just do this:
public interface ISimpleQuery
{
public class Input { }
public class Output { }
Task QueryAsync(Input input);
}
public class SimpleQuery : ISimpleQuery
{
public async Task QueryAsync(ISimpleQuery.Input input)
{
throw new NotImplementedException();
}
}
You can certainly do that. You can also simplify your Web API by giving it just one GET method that takes in "input" (via querystring, let's say) and returns "output". There are pros and cons to such dynamic approaches. YMMV. See also GraphQL.
@@Ardalis I would not do one generic query. I just gave an example of how it could be set up without having ICommandHandler generic. I don't think the generic is necessary.
@@vonn9737 Like I said, I see no reason why that wouldn't work.
"UseCases"... come on dude, what a complete and utter... ANNOYANCE, oh my god...
Its Application, you know it, I know it, we all know it, its Application.
Complete violation of SOLID principles: massive god-like repository objects and aggregates with side effects. Yikes. In real life all this will become untraceable spaghetti code very quickly: mediator doesn’t help much, there are some devs who still use auto mapper etc. How to maintain context for e.g. serilog and metrics beyond correlation ID? Overall sounds interesting on the surface, the code outcome is unimpressive.
So what type of architecture would you use? Some example?
Vertical slice architecture significantly better and way less layers and folders. Better code cohesion@@77Sazaca
in all honesty, you are 100% correct, I experienced it myself, things got so complicated that i gave up on everything and just did MVC 🤣
Use what works for you. This works well for many teams with real world apps. If you have suggestions for things that work better, by all means share them.
If you don't need it (yet), then you don't need it. Don't overcomplicate your solution unnecessarily. He already mentioned it very early in the presentation of when this might work and when it might not be. If it seems that it is too complicated for you, then most likely you don't need this (yet). More than likely tho, as complexity arises, consciously or unconsciously, you will arrive here. Either by learning about it like this or refactoring to something closer to this organically. 😅
Clean arch is cancer. We should retire it already.
When you see somebody writing DTO in class name all in capitals 😂, no need to look any further 😂😂😂. Bro, start with coding guidelines... Only after that, try to reinvent bycicles like you do.
Great Session, i loved it