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

How often have you done this 😂😂

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.

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

2

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.

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.

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.

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.

Probably trivial to swap out.

You got it in video: 25:52 min.

​@@MaxSupercarslink?

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.

It has been converted into a NuGet package.

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

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

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

Here's a whole presentation on the subject: ukposts.info/have/v-deo/n2aUnnmZr6dmlY0.html

Its an interface of an interface

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

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

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.

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