EntityFramweork Contexty - ile powinno być

Tworze sobie w ramach nauki aplikacje Asp.NET MVC + EntityFramework i tak się zastanawiam czy wszystkie DbSety wrzucać do jednego kontekstu, czy np lepiej podzielic to na rózne contexty.
Np teraz mam

public class InvoiceDbContext : DbContext
   {
       public DbSet<Header> Headers { get; set; }
       public DbSet<Item> Items { get; set; }
       public DbSet<Customer> Customers { get; set; }
       public DbSet<User> Users{get;set;}
   }

tutaj pytanie czy np Users czyli uzytkownicy aplikacji powinni byc w kontekscie faktury czy w takich przypadkach tworzy sie oddzielny kontekst?

Jeden kontekst per baza danych.

Możesz próbować mieć jeden context per bounded context (z DDD), ale nie wiem, czy EF to ogarnie.

Tak jak napisał @somekind, możesz mieć kilka kontekstów, ale wtedy na pewno pojawią się nowe problemy - transakcje pomiędzy kontekstami, migracje, zapewnienie integralności referencyjnej, współdzielenie typów pomiędzy kontekstami.

some_ONE napisał(a):

Tak jak napisał @somekind, możesz mieć kilka kontekstów, ale wtedy na pewno pojawią się nowe problemy - transakcje pomiędzy kontekstami, migracje, zapewnienie integralności referencyjnej, współdzielenie typów pomiędzy kontekstami.

Nie no, jeśli masz bounded contexty, to z definicji nie masz transakcji pomiędzy nimi, a integralnością zajmuje się i tak baza.
Mnie bardziej martwi generowanie bazy oraz migracje. Prawdopodobnie potrzeba by jeszcze jednego kontekstu EF na całą bazę.

A jak mam request, który coś tam robi w systemie i później musi zapisać dane do kilku kontekstów to tego nie obsługuje się transakcją na wiele kontekstów?

Jeśli masz taki request, to masz źle zdefiniowane bounded contexty.