Разница между несколькими контекстами в одной базе данных и несколькими базами данных

Question

Я разрабатываю с DDD, поэтому мне нужно создать контекст для ограниченного контекста.

У меня есть две альтернативы для монолитного дизайна:

1. Создание одной базы данных на контекст.
2. Создать одну базу данных для всех контекстов.

Для первого подхода я использую разные строки подключения (разные базы данных) для контекста.Для второго подхода я использую ту же строку подключения, но с другой схемой для контекста.

Я видел видео Джули Лерман, читал StackOverflow и программировал демонстрацию с EF Core, используя второй подход, но Я не понимаю реальной разницы между первым и вторым подходом.

Скриншот моей базы данных

Код моей демонстрации:

Контекст каталога

namespace Catalog
{
    public class CatalogContext : DbContext
    {
        public DbSet<Product> Products { get; set; }
        public DbSet<Category> Categories { get; set; }

        public CatalogContext(DbContextOptions options) : base(options)
        {
        }

        protected override void OnModelCreating(ModelBuilder modelBuilder)
        {
            modelBuilder.HasDefaultSchema("CatalogSchema");
            base.OnModelCreating(modelBuilder);
        }
    }

    public class CatalogContextFactory : IDesignTimeDbContextFactory<CatalogContext>
    {
        public CatalogContext CreateDbContext(string[] args)
        {
            var optionsBuilder = new DbContextOptionsBuilder<CatalogContext>();
            optionsBuilder.UseSqlServer(@"Server=(localdb)\mssqllocaldb;Database=TestingDddDatabase;Trusted_Connection=True;");

            return new CatalogContext(optionsBuilder.Options);
        }
    }
}

Контекст корзины

namespace Basket
{
    public class BasketContext : DbContext
    {
        public DbSet<Product> Products { get; set; }

        public BasketContext(DbContextOptions options) : base(options)
        {
        }

        protected override void OnModelCreating(ModelBuilder modelBuilder)
        {
            modelBuilder.HasDefaultSchema("BasketSchema");
            base.OnModelCreating(modelBuilder);
        }
    }

    public class CatalogContextFactory : IDesignTimeDbContextFactory<BasketContext>
    {
        public BasketContext CreateDbContext(string[] args)
        {
            var optionsBuilder = new DbContextOptionsBuilder<BasketContext>();
            optionsBuilder.UseSqlServer(@"Server=(localdb)\mssqllocaldb;Database=TestingDddDatabase;Trusted_Connection=True;");

            return new BasketContext(optionsBuilder.Options);
        }
    }
}

Answer 1

Однако существует разница, и принятое решение может повлиять на функциональные и нефункциональные атрибуты приложения.

С функциональной точки зрения: трудно предсказать, что должно делать ваше приложение, и более того, как оно может быть расширено в будущем, но, например, рассмотрим сценарий, когда вам нужно будет запросить некоторую агрегированную информацию из данных, связанных с несколькими ограниченнымиконтексты.Конечно, вы все равно можете выполнять запросы к нескольким базам данных, но вам нужно будет решать проблемы безопасности, поддерживая одинаковые учетные данные для чтения во всех базах данных и, возможно, проблемы с производительностью, если базы данных находятся в разных экземплярах или на разных компьютерах.Снова ограниченные контексты могут иметь отношения, которые могут потребовать дополнительных усилий для обеспечения согласованности между их данными.В одной базе данных это обычно решается с помощью транзакций, но если у вас есть несколько баз данных, вам придется иметь дело либо с распределенными транзакциями (что является другим зверем), либо с каким-то другим механизмом, который поддерживал бы вашу согласованность (очередь сообщений, источник событий,и т. д.) что может быстро усложнить ситуацию.С нефункциональной точки зрения подход, основанный на использовании нескольких баз данных, создает дополнительную сложность для оперативной деятельности, такой как создание и развертывание.Так что, если вы собираетесь использовать монолитный подход к приложениям, нет особых причин использовать несколько баз данных для этого.

Однако, если вы собираетесь разложить свое приложение на независимые компоненты / сервисы / микросервисы и т. Д., Связанные с ограниченным контекстом, чтобы улучшить масштабируемость приложения и процесса разработки, тогда вариант с несколькими базами данных хорошпутьЭто даст вам начальную точку для масштабирования приложения, снижения нагрузки транзакций на базы данных (оно будет распределено по разным базам данных / экземплярам / серверам), что снижает риск взаимных блокировок и может увеличить пропускную способность.Кроме того, будет проще поддерживать функциональность ограниченного контекста, так как он будет отделен от других компонентов посредством функциональной декомпозиции и декомпозиции источника данных.Такой подход очень типичен для архитектуры микроуслуг, потому что он дает упомянутые преимущества развязки, но вы должны быть уверены, что такая архитектура - то, с чем вы хотите пойти.

Итак, в качестве резюме - способ организации ваших данныхисходники - это архитектурное решение, и оно должно приниматься в сочетании с другими архитектурными решениями, принятыми для вашего приложения, исходя из значительных требований архитектуры, ограничений, KPI и других факторов, которые могут повлиять на вашу архитектуру, таких как состав команд, термины и т. д.

Answer 2

Насколько я понимаю ваши настройки, между этими двумя подходами не будет логической разницы, то есть вы получите разные хранилища данных для данных корзины и каталога.

То, что я считаю ДжулиВ ее курсе DDD объясняется использование отдельных контекстов EF для моделирования и доступа к данным для различных частей приложения (т. е. ограниченного контекста), в том числе Catalog & Basked в вашем примере.Физически отдельные контексты позволяют вам по-разному объявлять сущность Продукта (т. Е. Только соответствующие свойства) между двумя доменами - Каталог и Корзина - в зависимости от ваших потребностей.