This is not exactly The Clean Architecture style

[sk0va]

It might looks like Clean Architecture, but actually, it doesn't. The original principles are described here - https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html
The main principle of The Clean Architecture - The Dependency Rule, is broken in Application project, because it has reference to EF Core. Business layers must not depend on infrastructure layers, but commands use DbSet<> directly, to deal with data. It doesn't comply with The Clean Architecture principles.

The overriding rule that makes this architecture work is The Dependency Rule. This rule says that source code dependencies can only point inwards. Nothing in an inner circle can know anything at all about something in an outer circle. In particular, the name of something declared in an outer circle must not be mentioned by the code in the an inner circle. That includes, functions, classes. variables, or any other named software entity.

Also, domain entities in this solution more looks like a persistent layer entities, rather than domain layer entities.
The purpose of domain layer is to have pure domain abstractions and logic which are independent from application specific. Project may be called "Domain" and has some POCO classes, but if these entities are used mostly as EF Core entities, this is not a domain layer, actually...

They are the least likely to change when something external changes. For example, you would not expect these objects to be affected by a change to page navigation, or security. No operational change to any particular application should affect the entity layer.

It might looks like over-engineering to use separate entities levels for persistence and for domain layers, and all that mappings... Believe me, I'm pretty know, how annoying might be all these mappings! But there are reasons for that. This template solution is just relatively simple and didn't show all possible design issues which might appear in real-life applications... I.e., lets imagine, that we have two entities with many-to-many relation between them - Employee and Company. Yes, I know, this template is for .Net 5, but how about to apply this approach for .NET Core 3.1? In that case, we will need to have some intermediate joint entity to connect Employee with Company and vice versa, right? And queries to DB should use that entities to get related companies by employee and vice versa. But what about domain? do we really need this intermediate entity? The answer is NO, that entity is a persistence layer implementation details only, and it has no sense for domain logic. It useless for a domain logic and business logic. If you would have some other storage type with it's own ORM framework it might not needed in these entities, but it might use some other persistence-only entities. If you have a lot of many-to-many relations domain layer and business logic became harder to read and maintain in that case.

Other problem with Application layer, which uses DbSet<> directly, that it doesn't have unit tests for commands, only integration tests. It's is definitely better to check business logic of a command with unit tests instead of integration tests... Because unit tests are used to check correctness of business logic of a unit, and integration tests are used to checks integration between modules, right?

Presentation layer uses abstractions (commands) from business layer. This is the same kind of design decision issues as for persistence layer.
What if we need to provide additional API, with different entities but using the same logic? In this case we can't just reuse existent command and we will need to choose one of approaches - create new commands and extend existent handlers to support these commands, or introduce additional Response/Request DTO layer and map them to commands. Again, this solution is not showing how to deal with these real-life cases.

By separating entities by layers we are able to maintain layers completely separately. It make code much more flexible and testable, which is the main goal of The Clean Architecture. You may decide to use different UI layers simultaneously (i.e. REST API and message bus interface) for whatever reason, as well as use different persistence layer implementation without need to make changes to business logic.

Conforming to these simple rules is not hard, and will save you a lot of headaches going forward. By separating the software into layers, and conforming to The Dependency Rule, you will create a system that is intrinsically testable, with all the benefits that implies. When any of the external parts of the system become obsolete, like the database, or the web framework, you can replace those obsolete elements with a minimum of fuss.

This solution definitely should have more entity layers to became really an app in The Clean Architecture style.

Conclusion

If this template is called "Clean Architecture", it should follow The Clean Architecture principles. Otherwise, it definitely better to have some other name.

[karimkod]

@seoriy very good points.
I have already tried to answer your inquiry about the dependency on the DbSet in #439
As for defining DAOs for the persistence layers, the Fluent API creates a pretty clear abstraction between the persistence layer and the domain layers. What's the difference between having an API, that specifies what to persist and how to persist it, and having a DAO that would exist for the same reasons? I personally don't see any.

Yes, the presentation layer is using commands and triggering different use cases using those commands and queries which is a partial boundary (using Mediator) between the presentation layer and the application layer.

What if we need to provide additional API, with different entities but using the same logic

If you use different entities this would be a different use case i.e another horizontal slice in the app and should define its specific DTOs and use case (this is defined in the book under 'Decoupling use cases')

That's at least what I know and got from the book. After all, This is architecture (Not a religion) and architecture is built on decisions. You can definitely clone this template and change it to match your own decision.

Even, Uncle bob allowed some drifts from the original design of Clean Architecture, for instance, partial boundaries, and still called it Clean Architecture 💯

[se-trofimov]

The main principle of The Clean Architecture - The Dependency Rule, is broken in Application project, because it has reference to EF Core. Business layers must not depend on infrastructure layers, but commands use DbSet<> directly, to deal with data. It doesn't comply with The Clean Architecture principles.

I disagree with your point. EF Core is not an infrastructure. Infrastructure is DataBase, EF is just a tool. There is no dependency from DB, there is a dependency from EF core. But the same you have a dependency from .NET framework or BCL. I mean it is not reasonable to write an interface for each Framework class.
You can define an Interface IDbSet in application layer and override DbSet from EF
MyDbSet: DbSet, IDbSet - but it nothing changes..

[sk0va]

You can define an Interface IDbSet in application layer and override DbSet from EF

In that case it will be ok. As soon as we introduce own abstractions which completely hides chosen framework for implementations it is ok! In that case we will not need that reference to EF Core in Application project, so Dependency Rule will be followed. But the issue is exactly in direct use of DbSet<> inside Application layer and having reference from Application to EF Core and it breaks The Dependency Rule.

EF Core is not an infrastructure. Infrastructure is DataBase, EF is just a tool.

No, it is. As well as WebApi:

The outermost layer is generally composed of frameworks and tools such as the Database, the Web Framework, etc. Generally you don’t write much code in this layer other than glue code that communicates to the next circle inwards.

This layer is where all the details go. The Web is a detail. The database is a detail. We keep these things on the outside where they can do little harm.

He hasn't listed ORM directly here, but it definitely should be there. Otherwise, what layer it may be if not an Infrastructure layer (or "Frameworks&Drivers" from the original post)?

[odairto]

Omg, why the Handler (Application layer) has the context DB in it and why has DbSet TodoLists access?

[apolonas]

Have you watched the videos that explain clean architecture by Jason Taylor and also the videos about vertical slices by Jimmy Bogard? If you do then you will understand,

[karimkod]

@odairto Where is the context DB referenced, would you price the filename and line, please?

[odairto]

@odairto Where is the context DB referenced, would you price the filename and line, please?

Absolutely. See:

This is a direct Db access in app layer. I don't think that clean architecture say this...

GetCategoriesListQueryHandler

[karimkod]

@odairto I think you are in the wrong project, this is CleanArchitecture template, not Northwind project.

[odairto]

@odairto I think you are in the wrong project, this is CleanArchitecture template, not Northwind template.

You are right! Sorry!

[sk0va]

@odairto

Omg, why the Handler (Application layer) has the context DB in it

Not db context, but it uses DbSet<> from a db contexts directly...

[CraigComeOnThisNameCantBeTaken]

Personally I agree with the points raised, but then I never understood the difference between Clean Architecture and Onion Architecture to begin with.

My choice would be to use concrete repositories with the interfaces defined in the application later and implemented in the infrastructure layer. An example of why that matters can be seen when we think about database optimisation such as vertical partitioning, the virtual keywords, and breaking changes which DO happen (see EF Core 3). I do not believe it is a good idea to mix EF Core with business logic.

With that said I saw a talk from the author where he explained his decisions. If I recall this point was addressed as "I would rather embrace EF and have a simpler design. I find it so unlikely I will need flexibility to change db that I dont see an issue".

Its not for me, but this is a great project and I dont feel it strays from Clean Architecture, its just not purist and thats ok.

[Manuel-Iriarte]

Quoting the book, application layer (use cases) "We do not expect changes in this layer to affect the entities. We also do not expect this layer to be affected by changes to externalities such as the database, the UI, or any of the common frameworks. The use cases layer is isolated from such concerns."

So if i change entity framework or the database to for example a no sql DB, in those case i will have to change all the application layer. so I agree with the original point in this discussion.

[dk588]

I have checked this project to see how it solves the problem with the EF dependency needed by AspNetCore.Identity.
I was a bit disappointed to see it was not solve and there's a direct reference to sql server in the UI Project:

CleanArchitecture/src/WebUI/WebUI.csproj

Line 30 in de67f2f

<PackageReference Include="Microsoft.EntityFrameworkCore.SqlServer" Version="7.0.0-rc.2.22472.11" />

For those interested, the best approach to remove this dependency is to implement your custom storage provides.
Tim Schreiber wrote some good articles with full example: https://timschreiber.com/2015/01/14/persistence-ignorant-asp-net-identity-with-patterns-part-1/

Also you can find some Microsoft documentation here: https://learn.microsoft.com/en-us/aspnet/core/security/authentication/identity-custom-storage-providers?view=aspnetcore-6.0

[bayramerenn]

@sk0va I'm browsing repositories on GitHub for clean architecture and onion architecture, but for some reason, they all seem to apply the same approaches. Is there a repository you can recommend to me where I can see a clean architecture implementation?

[sk0va]

@bayramerenn Unfortunately, I also haven't found such a repo. But tbh, I wasn't searching for it diligently. I even thought about to try to write my own clean architecture example project, but it still just a dream because of lack of free time.

[ramax495]

@bayramerenn Unfortunately, I also haven't found such a repo. But tbh, I wasn't searching for it diligently.

Have you seen this repo https://github.com/ardalis/CleanArchitecture ?

[sk0va]

@bayramerenn, @ramax495 sorry for a long time without a response. Finally, I have some capacity now for a making some kind of Clean Architecture example project. You might find it in my sk0va/Taskforce repository. That's my point of view about how does a Clean-Architecture-style project may looks like. I hope I will have time to make some kind of template based on this repo in the future.

About ardalis/CleanArchitecture repository, I didn't investigated it deeply, tbh. But as far as can I see, it follows The Dependency Rule and has separated layers so it might be called Clean Architecture style project as for me. If I understand it right, this repo was created as demonstration for his "DD Fundamentals course" and it has more focus on demonstration of DDD aspects, like aggregation roots domain events, etc.

[jasontaylordev]

Hey everyone, it's great to see such a lively discussion about implementing Clean Architecture with ASP.NET Core, and I'd like to share my thoughts.

Instead of delving into each point individually, I'd like to emphasise that my approach to Clean Architecture is rooted in pragmatism and practicality. When creating a new solution, I always keep the principles of Clean Architecture in mind, while also staying attuned to the real-world context. It's important to strike a balance between adhering strictly to the principles and making reasonable trade-offs that align with the project's requirements. After all, each solution comes with its own unique set of considerations.

In some cases, the end result might be a solution that remains agnostic of specific frameworks, while in others, a more direct integration with certain frameworks might make sense. I would encourage each of you to adopt a similar mindset. Reflect on what truly matters for your particular solution and make well-informed implementation decisions.

So, while the template doesn't strictly adhere to the principles and does involve some trade-offs, it does offer a straightforward and accessible approach to Clean Architecture with ASP.NET Core in real-world scenarios. It can serve as an excellent starting point, helping you to quickly establish a solid foundation and providing a clear roadmap for customisation based on your project's specific needs.

[sk0va]

I also like the idea of using pragmatism as top-priority principle and thinking about each applications architecture as something, which should has more practical sense than academical purism in it. EF Core is a great framework! And I think, we all happy that Microsoft caringly enriched the .NET ecosystem with such a powerful ORM tool which makes our developers life easier.
But as I mentioned before, main issue with using EF Core directly in business layer, is the problem with testability. It is still hard to mock db context (and even not recommended by Microsoft), as well as testing queries, which makes unit testing of business logic very complicated. If you want to cover business layer with unit tests - the only good option is to separate business layer from EF Core through implementation of the Repository pattern on something like this.
Even if not every project will require unit tests at all and some of them can be covered with only integration tests, a lot of projects with complex domain logic will need unit tests.
As you may notice, concerns mentioned above has a very practical nature. And I suppose, a lot of developers, which will want to use your template, will think about what they are going to do with unit test coverage for their business logic...

[jasontaylordev]

Within the template I've adopted a holistic testing strategy that includes a range of unit, integration, and system tests. I don't mock the DbContext in any of these tests. For unit testing domain or application logic, I use the SQLite provider and the in-memory database feature. Configuring this is not difficult and it works well for a large number of cases. In integration tests, I use the relevant provider and the production-used database. This is necessary because testing database-specific behaviour, such as raw SQL, provider-specific transactions, or exact query behaviour, requires nothing less than the production database. The same approach is used for system tests.

Generally speaking, the above approach works well. That's why I've included it in the template. It's also the simplest approach, which aligns with a core goal of this template. However, there are instances where this approach is not suitable, and I will make adjustments accordingly. While I do implement the repository pattern from time to time, it's not to solve the issue of testing behaviour dependent on EF Core.

It's important to remember that this template can only serve as a starting point, and that it's not practical to create a template that will suit every possible scenario. I've tried to make the template as flexible as possible, but there will always be cases where you need to make adjustments. However, if you find yourself in a situation where you need to make a change, and you're not sure how to do it, please open an issue and I'll try to help.