Separate DbContext for Identity and business operations with same database - is there any advantages?

Question

I've started working on an existing ASP.NET Core project that uses the Identity framework. The application uses a single database. For some reason the application uses two separate database contexts - one derived from IdentityDbContext which of course is used for managing User/Auth and the other derived from DbContext which is used for anything other than User-related business.

I've seen previously applications using two separate database contexts, but every time they were using a separate database through the IdentityDbContext. Maybe the previous developer(s) were trying to achieve something not clear to me.

So, what could be some possible advantages, which I might be missing, in my scenario of using two separate contexts while the application have a single database? Thanks.

Edit:

My understanding is, since I have a single database I could easily use only the IdentityDbContext and it would serve every purpose which currently two separate contexts combined are serving. The application has various business entities (let's say Employee, Customer, Supplier, etc) which are not User of the application, but can be made one at some future point by registration with respective level of role-based privileges. In such a scenario, using only the IdentityDbContext gives me the advantage of creating one-to-one relationship with the AspNetUsers table, which I cannot implement now simply because of the separate contexts.

Answer 1

The only real "advantage", and it's slight, is that it conforms more to a bounded contexts philosophy: that each context should only work with a particular subdomain. However, in practical terms, you should also then have separate databases as well, or you're still mixing contexts. Additionally, if this is all in the same project, then there's zero point whatsoever. Even the idea of bounded contexts is a moot point in that scenario, since there's ultimately just one domain.

More likely than not, this was more accidental than intentional. When you create a new project with Individual User Accounts, an IdentityDbContext-derived class is added, to support the scaffolding. You can simply modify this scaffolded context to include your own additional entities, but particularly more green developers will often just add an additional context class for the app's entities. The fact that they're both using the same underlying database only leads credence to this being what likely occurred.

In short, there is no real advantage. The only benefit would come if you literally segregated these contexts such that the two were never available to the same project at the same time, i.e. they lived in separate class libraries and one or the other reference was added, depending on the particular domain the app is servicing. Short of that, it's entirely without point.