I am following the Microsoft Architecture Guide for creating an ASP.NET Core Web Application.
The guide implements the clean architecture pattern which is pretty straight forward.
If you look at the sample project which is using the clean architecture pattern you will see that there is an Infrastructure/Identity folder that contains the ApplicationUser.cs class.
I am using Entity Framework and one of my Business Entities in the ApplicationCore class library needs to contain a list of ApplicationUser. The ApplicationCore library shouldn't be referencing any other projects. It contains all of the Interfaces and Business Entities. How can I keep the ApplicationUser class in my Infrastructure/Identity project and still use it in one of my business entities in the ApplicationCore project without breaking the rules.
I know one solution is to not store the ApplicationUser entity in my Infrastructure project. However, I feel like it should be there since it will always rely on Identity as it implements IdentityUser.
In Clean Architecture:
Application Core Types
â€¢ Entities (business model classes that are persisted) and Aggregates
â€¢ EF Core types (DbContext, Migrations)
â€¢ Data access implementation types (Repositories)
â€¢ Infrastructure-specific services (FileLogger, SmtpNotifier, etc.)
So the ApplicationUser.cs is an entity, it shouls be in Application Core
User is an entity and it should be in Core layer.
But you shouldn't use
ApplicationUser : IdentityUser in the Core layer because it's tied up to the ASP.NET Identity. The Core layer should not know what technologies are going to implement the domain.
What if tomorrow you want to use another library for user management? That's not the Core layer's concern.
What you can do is to use an interface or base User class in the Core layer and let the Infrastructure layer be worried about the library choice decision.