Question

我正在使用DDD进行开发，因此需要为每个有界上下文创建一个上下文。

对于整体设计，我有两种选择：

为每个上下文创建一个数据库。
为所有上下文创建一个数据库。

对于第一种方法，我为每个上下文使用不同的连接字符串（不同的数据库）。对于第二种方法，我使用相同的连接字符串，但每个上下文具有不同的架构。

我已经看过朱莉·勒曼（Julie Lerman）的视频，阅读了StackOverflow并使用第二种方法使用EF Core编程了一个演示，但是我不理解第一种方法和第二种方法之间的真正区别。

我的数据库截图

我的演示代码：

目录上下文

Sub ChangeAllPics()
Dim s As Shape
For Each s In ActiveSheet.Shapes
s.Select
    s.Width = 500
    s.Height = 200
Next s
End Sub

购物篮上下文

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

Answer 1

据我了解您的设置，这两种方法之间没有逻辑上的区别，这意味着您最终将获得用于购物篮和目录数据的不同数据存储。

我相信Julie在DDD课程中所解释的是使用单独的EF上下文来为应用程序的不同部分（即有限上下文）（在您的示例中为Catalog＆Basked）建模和访问数据。物理上分开的上下文使您可以根据需要在两个域（目录和购物篮）之间声明不同的Product实体（即，仅相关属性）。

Answer 2

但是存在差异，因此做出的决定可能会影响应用程序的功能和非功能属性。

从功能的角度来看：很难预测应用程序应该做什么，而且很难将来扩展它，但是例如，考虑当您需要从与多个有界上下文相关的数据中查询一些汇总信息时的情况。当然，您仍然可以执行跨数据库查询，但是您需要通过在所有数据库中支持相同的读取凭据来解决安全性问题，如果数据库位于不同的实例或位于不同的计算机上，则可能存在性能问题。再次，有界上下文可能具有关系，可能需要付出额外的努力来支持其数据之间的一致性。在单个数据库中，通常可以通过事务处理来解决，但是如果您有多个数据库，则必须处理分布式事务（这是另一种野兽）或其他支持您的一致性的机制（消息队列，事件源，等），这可能会使事情变得有些复杂。从非功能性的角度来看，多数据库方法给诸如构建和部署之类的操作活动带来了额外的复杂性。因此，如果您要使用整体应用程序方法，则没有理由为此使用多个数据库。

但是，如果要将应用程序分解为与有限上下文相关的独立组件/服务/微服务等，以提高应用程序和开发过程的可伸缩性，那么选择多个数据库是一个不错的选择。这将为您提供扩展应用程序的起点，减少数据库上的事务负载（它将分布在不同的数据库/实例/服务器之间），从而降低了死锁的风险并可能提高吞吐量。除此之外，由于它会通过功能和数据源分解与其他组件分离，因此更容易维护有限的上下文功能。这种方法在微服务架构中非常典型，因为它具有上述提到的去耦优势，但是您应该确保要使用这种架构。

因此，作为总结，组织数据源的方式是体系结构决策，应结合针对体系结构的重要要求，约束，KPI以及可能影响其他方面的其他因素为应用程序制定其他体系结构决策您的架构，例如团队组成，条款等。

一个数据库和多个数据库中的多个上下文之间的差异

2 个答案: