Difference between multiple contexts in one database and multiple databases

c# domain-driven-design entity-framework-core

Question

I'm developing with DDD, so I need to create a context per bounded context.

I have two alternatives for a monolithic design:

  1. Create one database per context.
  2. Create one database for all contexts.

For the first approach, I use a different connection string (different database) per context. For the second approach, I use the same connection string, but with a different schema per context.

I have seen the Julie Lerman's videos, read StackOverflow and programmed a demo with EF Core using the second approach, but I don't understand the real difference between the first and second approach.

Screenshot of my database

enter image description here

Code of my demo:

Catalog context

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);
        }
    }
}

Basket context

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);
        }
    }
}
1
-1
9/25/2018 5:03:29 PM

Accepted Answer

The difference however exists and decision made on that may impact functional and non-functional attributes of the application.

From the functional perspective: it's hard to predict what your application should do and moreover how it can be extended in future but for example consider scenario when you'd need to query some aggregated information from data related to multiple bounded contexts. Of course you can still perform cross-database queries but you'll need to address security problems by supporting same read credentials across all databases and possibly performance problems if the databases are in different instances or on different machines. Again bounded contexts may have relationships which may require extra effort to support consistency between their data. In a single database it's typically solved by means of transactions but if you have multiple databases you'll have to deal either with distributed transactions (which is another beast) or with some other mechanism which would support your consistency (message queue, event sourcing, etc) which quickly may make things bit complicated. From the non-functional perspective the multi-databases approach imposes extra complexity to the operational activities like building and deployment. So if you're going to go with a monolith application approach there is little reason to use multiple databases for that.

However if you're about to decompose your application to independent components/services/micro-services, etc. related to the bounded contexts in order to improve the application and development process scalability then option with multiple databases is good way to go. It will give you start point to scale application out, reduce transactions load on databases (it will be distributed across different databases/instances/servers) which decreases risk of dead-locks and may increase the throughput. Apart from that it will be easier to maintain the bounded context functionality as it will be decoupled from other components by means of functional and data source decomposition. Such approach is very typical for micro-services architecture because it gives mentioned decoupling benefits but you should be sure that such architecture is something you want to go with.

So as a summary - the way how you organize your data sources is architectural decision and it should be made in conjunction with other architectural decisions made for you application basing on the architecture significant requirements, constraints, KPI's and other things which may affect your architecture like team compositions, terms, etc.

0
9/25/2018 6:39:22 PM

Popular Answer

As far as I understand your setup, there will be no logical difference between the two approaches, meaning, you'll end up with different data stores for Basket and Catalog data.

What I believe Julie is explaining in her DDD course is using separate EF contexts to model & access data for different parts of the application (i.e. bounded contexts), Catalog & Basked in your example. The physically separate contexts allow you to have a Product entity declared differently (i.e. only relevant properties) between the the two domains - Catalog & Basket - depending on your needs.



Related Questions





Related

Licensed under: CC-BY-SA with attribution
Not affiliated with Stack Overflow
Licensed under: CC-BY-SA with attribution
Not affiliated with Stack Overflow