Clean Architecture with ASP.NET Core 8 | .NET Conf 2023

[@EzDoesntExist]

Steve is a gift for .net community

[@9739718777]

Great, Thank you Steve. I am .NET dev but not into web development. But I could follow easily. Its clean.

[@kenuahs]

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]

Thanks!

[@ricardos3756]

To the person who asked about CQRS vs Specifications. I believe you may be looking at it as if linq was only used with data coming from the database. As you know they can work together, and they do most of the time, but let's not forget that Linq is also useful with many other object types, not just data, and I believe it is in those scenarios, where you may find yourself applying the same Linq code multiple times, and this is where you will benefit from having Specifications.

[@chockshoway]

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

[@mattymattffs]

If you look at MS implementations, e.g. the ERP solutions, you'll see that it often does use this design (not always religiously)

[@vishweshhramesh2163]

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

[@Ardalis]

Thanks!

[@Jason_Shave]

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.

[@bvboi]

Currently implementing this in my project. Thanks!

[@JasonWilliams-b3e]

Thank You loads of success!!

[@mrohailiqbal]

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

[@calvinwilson3617]

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]

How often have you done this 😂😂

[@fboucheros]

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.

[@jan5310]

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.

[@FockewulfAz]

Fantastic! God bless you!

[@HiepDuong-q8f]

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]

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.

[@acodersjourney]

Your channel is a treasure trove of knowledge. Thanks!

[@Paul-uo9sv]

This is the best video yet on clean architecture

[@sanju0099]

excellent, great Job!

[@martinaaron7304]

Really great video. Learned a lot.

[@YanEyene]

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]

it's not a silver bullet.

[@MikhailAksenovV]

It depends on what you're doing. If you're writing a simple CRUD that's totally fine to go with a simple CRUD. Problems starts when you have transactional boundaries spanning many objects and orchestrating complex workflows. So there is upfront complexity, but it will worth it _if_ essential complexity of the system is high.

[@FainTMako]

Great presentation. One of my favorites from this year!

[@DenisioRodrigues]

Great! Very nice!

[@mumk]

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

2

[@TheKevlar]

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

[@bmassioui]

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]

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.

[@kell7689]

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]

I have pretty much the same view on this

[@Ardalis]

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.

[@mattymattffs]

Microsoft business Central, but the code is not public

[@aiman1562]

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

[@rguere]

thanks so much. my project run ok..

[@american_coder]

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.

[@Marcin-jz8qp]

Superb!

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

Correct, but for any relational queries and in many other scenarios (behavior around joins and .Include, etc) the InMemory provider falls down.

[@christianf7740]

Great stuff

[@weicco]

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.

[@sdudnic]

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

[@olivier0003]

Good Job :)

[@ferreimavi1998]

Wow, just wow 👏👏👏

[@Ardalis]

Thanks!

[@0w784g]

Talk about how you handle transactions in this architecture. All software looks clean when it's a glorified todo list.

[@ivanpavlovnorth]

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.

[@mediabox6307]

Hello, awesome 👏 Where to put a sendingnotification by SignalR ? I suppose to create a DomaineventHandler wish use an interface, and Will the interface implemented in the infrastructure Project switch a SignalR client ?

[@bohdan-belei]

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]

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]

Thanks for the answer, Ardalis.

[@wadeaashraf2761]

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]

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.

[@bmiller949]

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

[@nobir98]

Nice!!

[@mattdoa2]

16:01 - Isn't it true that you might never easily understand what has subscribed to your event? (So by changing the event name or removing it, you could cause a lot of issues with event handlers). I'm imagining this becoming a source of technical debt (in terms of complexity to maintain and complexity to clean up).

[@ctwoodwa]

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

[@Ardalis]

Probably trivial to swap out.

[@hectorcontreras9171]

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]

They're all pretty similar, as the general concepts haven't changed. No need to watch earlier ones.

[@auronedgevicks7739]

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

[@wanderingxsx]

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)

[@slobodanmikaric2180]

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]

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.

[@amrswalha]

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

[@MaxSupercars]

You got it in video: 25:52 min.

[@Paul-uo9sv]

​@@MaxSupercarslink?

[@maltonic42]

@@MaxSupercars I cannot see the Todo-Sample there and nowhere else. I would like to have exactly the source code, like in the video...

[@jimmiedavis434]

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]

@@jacobstamm Agreed.

[@shashankshekhar-cl7rd]

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

[@jonaszjonasz5752]

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

[@sadukie]

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

[@liski12]

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]

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]

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.

[@jacobstamm]

REPR pattern, MediatR, third-party DbContext wrapper… why so many extra moving parts for a demo?

[@Ardalis]

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.

[@rmbl349]

Whats the difference to Jason Taylors Template?

[@Ardalis]

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

[@svorskemattias]

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

[@nikogj9495]

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]

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

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

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

[@Ardalis]

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

[@dilakshaaveesh4360]

where can I get the slides? Is it free?

[@brenthompson2]

Tell me more about `IRepository`

[@Ardalis]

Here's a whole presentation on the subject: kzbin.info/www/bejne/nWfGm3aYrdZoars

[@Andy-si1pl]

Its an interface of an interface

[@ttyy544]

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]

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

[@walisonleiria]

Hello! where is the Shared Kernel repository?

[@zaighamgulzar1927]

It has been converted into a NuGet package.

[@hakami1426]

4:30. 21:26

[@PaulMarangoni]

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]

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.

[@MrSchmell]

Microsoft did CA fans dirty with EF. It's absolutely hilarious how this thing does not fit whatever you do: 1) You wrap around the whole thing to get feature parity, but then you get an empty wrapper and an "abstraction" that is a carbon copy of EF API with EF-specific way of doing things 2) You don't wrap around the whole thing - you get crippled lowest common denominator abstraction, which is fine for simpliest projects, but then why bother? - IRepositoryBase is somehow both 1 and 2 - it's a copy of DbContext API, but only part of it 3) You use it directly (like the other CA guy - Milan - proposes), and break your methodology completely.

[@karthiks4347]

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

[@MrShurminator]

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]

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]

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

[@camrws]

hi

[@vonn9737]

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]

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]

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

@@vonn9737 Like I said, I see no reason why that wouldn't work.

[@musigahstallone]

this works like aspire dotnet is that true?

[@Ardalis]

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

[@ЕвгенийНазаров-н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]

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

[@MrAyuub22]

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

[@imam4521]

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]

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]

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

[@vladhusnullin1650]

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

[@leolucas4922]

Like what?

[@jacobstamm]

Well? If you have a valid critique, say it.

[@fieryscorpion]

Clean arch is cancer. We should retire it already.

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

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]

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]

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

[@CodeTricksDotTips]

Great Session, i loved it