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).
@kenuahs
3 ай бұрын
I've read dozens of articles over the years on clean architecture, and a portion of those were tied in to .net apps, and this is by far the best presentation on clean architecture that I have seen! Was especially helpful to see a real-live project as well. Super well done presentation.
@Ardalis
2 күн бұрын
Thanks!
@bvboi
Ай бұрын
Currently implementing this in my project. Thanks!
@calvinwilson3617
9 ай бұрын
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.
@Tvde1
9 ай бұрын
How often have you done this 😂😂
@vishweshhramesh2163
6 ай бұрын
Best video to understand CQRS, Clean Architecture without any clutter.
@Ardalis
2 күн бұрын
Thanks!
@9739718777
21 күн бұрын
Great, Thank you Steve. I am .NET dev but not into web development. But I could follow easily. Its clean.
@EzDoesntExist
5 ай бұрын
Steve is a gift for .net community
@Jason_Shave
9 ай бұрын
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.
@bmassioui
8 ай бұрын
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 👍
@Ardalis
2 күн бұрын
I used to have more of them in the project(s) directly but they were useful on their own as well (they have millions of package downloads) and it didn't make sense to maintain them in two places. They're all MIT license so if you want to just copy-paste the code into your company's source repo you're welcome to do so.
@jan5310
9 ай бұрын
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.
@mrohailiqbal
8 ай бұрын
It was a good learning experience through this video. Keep it up.
@user-nw7jo5xw9x
8 ай бұрын
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 😢)
@Ardalis
2 күн бұрын
My usual recommendation for folks in your situation is to consider moving from microservices to a modular monolith approach for most if not all of the services. Usually the pain is coming more from the microservices than from whether an individual microservice was built using CA or VSA or YOLO or whatever organizational structure. I published a few courses earlier this year on Modular Monoliths on Dometrain for anyone interested in what that looks like with real code in .NET 8.
@fboucheros
9 ай бұрын
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.
@sanju0099
4 ай бұрын
excellent, great Job!
@ferreimavi1998
4 ай бұрын
Wow, just wow 👏👏👏
@Ardalis
2 күн бұрын
Thanks!
@acodersjourney
9 ай бұрын
Your channel is a treasure trove of knowledge. Thanks!
@kell7689
7 ай бұрын
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.
@alexandrucioarec6554
6 ай бұрын
I have pretty much the same view on this
@Ardalis
5 ай бұрын
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.
@mumk
9 ай бұрын
great to see Ardalis here, I knew him from his Pluralsight course
9 ай бұрын
2
@Paul-uo9sv
9 ай бұрын
This is the best video yet on clean architecture
@aiman1562
5 ай бұрын
I would super appreciate a dark background. For those many with bad eyes
@FockewulfAz
7 ай бұрын
Fantastic! God bless you!
@martinaaron7304
8 ай бұрын
Really great video. Learned a lot.
@FainTMako
9 ай бұрын
Great presentation. One of my favorites from this year!
@DenisioRodrigues
7 ай бұрын
Great! Very nice!
@user-fv7oh9ig4q
8 ай бұрын
imo - this is way more complex than it should be
@kronostitan11
4 ай бұрын
That’s kind of the point. It’s not supposed to be for very simple applications
@ecblanco
2 ай бұрын
it's not a silver bullet.
@christianf7740
9 ай бұрын
Great stuff
@jacobstamm
Ай бұрын
By using raw SQL queries instead of starting with an entity and doing a .Select() from that, it’s worth noting that using the EF InMemory data provider isn’t going to be enough for your unit tests
@Ardalis
2 күн бұрын
Correct, but for any relational queries and in many other scenarios (behavior around joins and .Include, etc) the InMemory provider falls down.
@frankhoffy
9 ай бұрын
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.
@olivier0003
9 ай бұрын
Good Job :)
@ivanpavlovnorth
9 ай бұрын
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.
@Marcin-jz8qp
9 ай бұрын
Superb!
@weicco
7 ай бұрын
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.
@TheKevlar
9 ай бұрын
I like the idea of eliminating Swagger and Postman this makes remote code reviews clean...
@wadeaashraf2761
9 ай бұрын
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
@Ardalis
9 ай бұрын
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.
@ctwoodwa
9 ай бұрын
Has anyone looked into using the wolverine library instead of mediatr?
@Ardalis
9 ай бұрын
Probably trivial to swap out.
@bohdan-belei
8 ай бұрын
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!
@Ardalis
5 ай бұрын
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.
@bohdan-belei
5 ай бұрын
Thanks for the answer, Ardalis.
@slobodanmikaric2180
9 ай бұрын
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?
@Ardalis
9 ай бұрын
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.
@rguere
5 ай бұрын
thanks so much. my project run ok..
@sdudnic
7 ай бұрын
how should we link the client project here, like Angular application? I suppose a folder like Client to add to the Web solution?
@bmiller949
6 ай бұрын
I would like the see the requirements documentation that this application satisfies.
@amrswalha
9 ай бұрын
Hello, thanks for the presentation. Where we can access the source code?
@MaxSupercars
9 ай бұрын
You got it in video: 25:52 min.
@Paul-uo9sv
9 ай бұрын
@@MaxSupercarslink?
@maltonic42
2 ай бұрын
@@MaxSupercars I cannot see the Todo-Sample there and nowhere else. I would like to have exactly the source code, like in the video...
@nobir98
9 ай бұрын
Nice!!
@jonaszjonasz5752
7 ай бұрын
Hi, why didn't you add subtitles to the film?
@sadukie
7 ай бұрын
There are subtitles. You may need to press the CC button to enable subtitles/closed captions.
@PaulMarangoni
9 ай бұрын
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.
@Ardalis
9 ай бұрын
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.
@auronedgevicks7739
8 ай бұрын
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
@shashankshekhar-cl7rd
4 ай бұрын
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
@rmbl349
9 ай бұрын
Whats the difference to Jason Taylors Template?
@Ardalis
9 ай бұрын
I haven't looked recently enough to say with confidence.
@hectorcontreras9171
8 ай бұрын
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?
@Ardalis
2 күн бұрын
They're all pretty similar, as the general concepts haven't changed. No need to watch earlier ones.
@hakami1426
2 ай бұрын
4:30. 21:26
@svorskemattias
9 ай бұрын
Doesn't your specifications have ef core references? Looks like that, with that Include-method
@nikogj9495
9 ай бұрын
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.
@svorskemattias
9 ай бұрын
@@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.
@nikogj9495
9 ай бұрын
@@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
@svorskemattias
9 ай бұрын
@@nikogj9495 yes. Then we agree. This domain layer is coupled to infrastructural concerns.
@Ardalis
9 ай бұрын
@@nikogj9495 It would be weird if it were the case.
@jimmiedavis434
3 ай бұрын
What is the starting point to be able to comprehend the presentation? I'm learning .NET but this is over my head on understanding it.
@jacobstamm
Ай бұрын
I would say that besides C# fundamentals, having a baseline understanding of ASPNET Core (preferably WebAPI) controllers, Entity Framework (specifically entities and DbContext), and dependency injection will allow you to get the most out of this. In my opinion, the author’s inclusion of extra pieces like MediatR and the REPR pattern added a bit of complexity that raises the barrier of entry and isn’t necessary to understand Clean Architecture, so don’t worry about those parts too much.
@Ardalis
2 күн бұрын
@@jacobstamm Agreed.
@brenthompson2
9 ай бұрын
Tell me more about `IRepository`
@Ardalis
9 ай бұрын
Here's a whole presentation on the subject: kzitem.info/news/bejne/yGyZ0HeYsaNmZ44
@Andy-si1pl
8 ай бұрын
Its an interface of an interface
@jacobstamm
Ай бұрын
REPR pattern, MediatR, third-party DbContext wrapper… why so many extra moving parts for a demo?
@Ardalis
2 күн бұрын
A pattern isn't a moving part. MediatR is optional but useful. Depending on data access directly has tradeoffs - in Clean Arch / Ports and Adapters you don't depend directly on infrastructure but rather on an adapter implementation that you own.
@wanderingxsx
4 ай бұрын
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)
@liski12
8 ай бұрын
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?
@obedasante2168
8 ай бұрын
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.
@Ardalis
5 ай бұрын
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.
@walisonleiria
8 ай бұрын
Hello! where is the Shared Kernel repository?
@zaighamgulzar1927
5 ай бұрын
It has been converted into a NuGet package.
@dilakshaaveesh4360
2 ай бұрын
where can I get the slides? Is it free?
@ttyy544
7 ай бұрын
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...
@Ardalis
5 ай бұрын
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).
@MrShurminator
8 ай бұрын
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.
@Andy-si1pl
8 ай бұрын
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...?
@Ardalis
2 күн бұрын
@@Andy-si1pl Exactly! Why hard-code to things that will be replaced in a few years? Instead, build interfaces for your infrastructure needs and use adapters (implementations of these interfaces) so that later when the world changes, you can just write a new adapter. You've understood one of the many benefits of this approach!
@karthiks4347
3 ай бұрын
I liked the show but the presentation was too fast, could have been little slow like an hour. Thanks.
@path_selector
9 ай бұрын
hi
@musigahstallone
9 ай бұрын
this works like aspire dotnet is that true?
@Ardalis
9 ай бұрын
No, I don't think it's really related.
@vonn9737
9 ай бұрын
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(); } }
@Ardalis
9 ай бұрын
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.
@vonn9737
9 ай бұрын
@@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.
@Ardalis
9 ай бұрын
@@vonn9737 Like I said, I see no reason why that wouldn't work.
@fieryscorpion
6 ай бұрын
Clean arch is cancer. We should retire it already.
@user-eo5rq7qy7g
9 ай бұрын
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.
@77Sazaca
9 ай бұрын
So what type of architecture would you use? Some example?
@MrAyuub22
9 ай бұрын
Vertical slice architecture significantly better and way less layers and folders. Better code cohesion@@77Sazaca
@imam4521
9 ай бұрын
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 🤣
@Ardalis
9 ай бұрын
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.
@jchandra74
9 ай бұрын
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. 😅
@CodeTricksDotTips
9 ай бұрын
Great Session, i loved it
@vladhusnullin1650
5 ай бұрын
I am so dissapointed when I see somebody coding like this 😂😂😂
@leolucas4922
2 ай бұрын
Like what?
@jacobstamm
Ай бұрын
Well? If you have a valid critique, say it.
@JonathanCrossland
Ай бұрын
This idea that we have to abide by a bunch of peoples idea of architecture and "clean" is silly. .net core makes simple things complicated. "Clean" architecture adds three times the amount of code to maintain. Aweful way to build code. This template to get an email for an API - is just ridiculous.
@Ardalis
2 күн бұрын
If you don't need it don't use it. If you've experienced codebases that are tightly coupled to infrastructure in many places, you may find value in loose(r) coupling achieved by this approach.
@vladhusnullin1650
5 ай бұрын
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.
@MarvijoSoftware
2 ай бұрын
You're attempting to force your own coding guidelines on him, don't you think? Readability is key. SUVVehicle, SuvVehicle or SUV:Vehicle is a style choice, Suv isn't very readable
Пікірлер: 139