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.

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 🙂

@RunawayYe

6 ай бұрын

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.

@alexandermackintosh1755

3 ай бұрын

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

Fantastic! God bless you!

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

4 ай бұрын

I have pretty much the same view on this

@Ardalis

2 ай бұрын

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 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).

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 😢)

Best video to understand CQRS, Clean Architecture without any clutter.

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.

It was a good learning experience through this video. Keep it up.

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.

Your channel is a treasure trove of knowledge. Thanks!

Great presentation. One of my favorites from this year!

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 👍

Really great video. Learned a lot.

excellent, great Job!

Steve is a gift for .net community

Great! Very nice!

Wow, just wow 👏👏👏

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.

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

6 ай бұрын

How often have you done this 😂😂

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.

Superb!

thanks so much. my project run ok..

This is the best video yet on clean architecture

Good Job :)

Great stuff

Nice!!

great to see Ardalis here, I knew him from his Pluralsight course

6 ай бұрын

2

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

6 ай бұрын

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.

how should we link the client project here, like Angular application? I suppose a folder like Client to add to the Web solution?

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

2 ай бұрын

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

2 ай бұрын

Thanks for the answer, Ardalis.

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.

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

6 ай бұрын

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.

imo - this is way more complex than it should be

@kronostitan11

Ай бұрын

That’s kind of the point. It’s not supposed to be for very simple applications

@ecblanco

5 күн бұрын

it's not a silver bullet.

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?

I would like the see the requirements documentation that this application satisfies.

Has anyone looked into using the wolverine library instead of mediatr?

@Ardalis

6 ай бұрын

Probably trivial to swap out.

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

6 ай бұрын

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

2 ай бұрын

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 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

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.

Hello, thanks for the presentation. Where we can access the source code?

@MaxSupercars

6 ай бұрын

You got it in video: 25:52 min.

@Paul-uo9sv

6 ай бұрын

​@@MaxSupercarslink?

Doesn't your specifications have ef core references? Looks like that, with that Include-method

@nikogj9495

6 ай бұрын

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

6 ай бұрын

@@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

6 ай бұрын

@@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

6 ай бұрын

@@nikogj9495 yes. Then we agree. This domain layer is coupled to infrastructural concerns.

@Ardalis

6 ай бұрын

@@nikogj9495 It would be weird if it were the case.

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.

I would super appreciate a dark background. For those many with bad eyes

Whats the difference to Jason Taylors Template?

@Ardalis

6 ай бұрын

I haven't looked recently enough to say with confidence.

I like the idea of eliminating Swagger and Postman this makes remote code reviews clean...

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)

Hi, why didn't you add subtitles to the film?

@sadukie

4 ай бұрын

There are subtitles. You may need to press the CC button to enable subtitles/closed captions.

where can I get the slides? Is it free?

Hello! where is the Shared Kernel repository?

@zaighamgulzar1927

2 ай бұрын

It has been converted into a NuGet package.

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

this works like aspire dotnet is that true?

@Ardalis

6 ай бұрын

No, I don't think it's really related.

Tell me more about `IRepository`

@Ardalis

6 ай бұрын

Here's a whole presentation on the subject: kzread.info/dash/bejne/mWqXzKWbqNSbZLw.html

@Andy-si1pl

5 ай бұрын

Its an interface of an interface

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

2 ай бұрын

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).

I am so dissapointed when I see somebody coding like this 😂😂😂

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

6 ай бұрын

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.

hi

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

5 ай бұрын

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...?

I liked the show but the presentation was too fast, could have been little slow like an hour. Thanks.

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

6 ай бұрын

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

6 ай бұрын

@@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

6 ай бұрын

@@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.

Clean arch is cancer. We should retire it already.

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

6 ай бұрын

So what type of architecture would you use? Some example?

@MrAyuub22

6 ай бұрын

Vertical slice architecture significantly better and way less layers and folders. Better code cohesion@@77Sazaca

@imam4521

6 ай бұрын

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

6 ай бұрын

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

6 ай бұрын

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. 😅

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