identity in Clean Architecture

[asgharb]

hi.
I use Clean architecture and implement identity in presentation layer .
But according to the clean architecture, identity data should not be placed there. Where should Identity packages and folders be located in clean architecture asp core?

[kingjordan]

you can see that identity is part of infrastructure. Look in that project for identity services etc...

[Bahri-Haythem]

I faced the same situation as @asgharb where I wanted to reference the ApplicationUser in webUI but according to the best practices infrastructure should only be referenced for DI. Should I create an interface IApplicationUser in the application layer and inject it or what?

[asgharb]

you can see that identity is part of infrastructure. Look in that project for identity services etc...

Why is the ApplicationUser class in the Infrastructure project?

[MichaelHochriegl]

I too struggle with this. For learning-purpose I currently build a bug tracker (with Blazor as frontend) and want to use OpenIddict as an IDP. My domain has entities, that need the user (e.g. a project-team consists of many users, a issue/ticket has a user assigned, ...).

How should I best handle this?

[riiight]

Any update on this?

[Nizar-Almshantaf]

any update on this ? I also want to reference the user in some of my entities.

[jasontaylordev]

The template isolates ApplicationUser within Infrastructure, since it depends on IdentityUser. IdentityUser comes from ASP.NET Core Identity, and ideally, it's best to avoid dependencies on other frameworks within Core (the Application and Domain layers form Core).

If you are not concerned about a dependency on ASP.NET Core Identity, move ApplicationUser into the Domain. It will then be relatively simple to extend Identity and access ApplicationUser within Core.

If you want to remain independent of ASP.NET Core Identity, the missing piece is a Domain entity representing your users, let's keep it simple and create a User entity in the Domain:

public class  User
{
  public int Id { get; set; }
  public string ApplicationUserId { get; set; } // You could also just make this the primary key.

  public string Name { get; set; }
  public string Email { get; set; }
}

This class represents the user within your Domain. Other Domain entities, can include navigation properties to this entity. For example:

public class  Message
{
  public int Id { get; set; }
  public int SenderId { get; set; } // This is the user Id foreign key
  public string Text { get; set; }

  public User Sender { get; set; }
}

With the above approach, the Domain is independent of the ASP.NET Core Identity. However, some effort is required to achieve this independence. For example, the User and ApplicationUser will share similar data, such as Email. If the user updates their profile, you must update it in two places.

Your approach should always depend on the technical requirements of the solution you are building. Happy Coding! 😀