应该为每个边界上下文设置一个数据库到规则，还是单独的数据库

这取决于它们是否只共享同一个数据库或某些表 - 即数据。

共享

数据库但不共享表是完全可以的。除非您的目标是可伸缩性并打算使 BC 的可独立部署和可运行单元（如微服务）成为可能，在这种情况下，它们可能应该拥有自己的数据存储实例。

我看到 2 个或更多绑定上下文共享的数据库表还有一些缺点：

• 紧密耦合。我们拥有不同的BC的原因是它们代表不同的领域空间，这些空间可能会以自己的方式发散。更改其中一个 BC 中的概念可能会影响基础表，迫使使用此表的其他 BC 也更改。在应该柔软的地方得到刚性。由于多个可能的更改源，数据中还可能存在不一致或"漏洞"。

• 并发。在高并发系统中，某些实体和下面的表会受到强争用的影响。边界上下文是通过分离不同类型的写入来减轻负载的方法之一，但仅当它们在一天结束时不锁定相同的数据时才有效。对于非 CQRS 系统中的读取也是如此，它们查询完成写入的同一数据库。

• ORM友好。大多数 ORM 不允许你映射到同一个数据库表中的 2 个或更多类，而无需大量的卷积和解决方法。

如果每个BC都有自己的数据库，应该如何构建应用程序。

在某种程度上（例如，可能包括或不包括UI层），就像您有多个单独的应用程序一样。如果您有确切的问题，请更具体。

在每个有界上下文中具有此垂直切片的想法是，每个 BC 与其他每个 BC 的关系以及它们之间的通信应根据领域知识而不是持久性技术的技术优点来考虑和设计。

如果您的客户位于 2 个不同的 BC，则会导致一种参与者模式情况。 如果支持业务人员在销售业务委员会中创建新客户时需要了解新客户，则销售业务人员需要连接到支持业务委员会上的已知接口，并向其传递此新信息。 一个域与另一个域交谈。 它非常接近地模拟了来自不同部门的人们相互交谈时在现实生活中的工作方式。

如果你共享一个大数据库（你在这里谈论的是定制的企业软件，所以在野外不会有很多例子），那么诱惑就是绕过在领域层中捕获的所有领域专业知识，并干预另一个BC的数据库。 事情很快就变成了一个大泥球。

令人惊讶的是，我在现实世界中经常看到这种事情，我认为这是非常糟糕的做法。

这有点取决于它们是自己的数据库的原因。界定上下文的概念是，您有一组相互关联的实体并共同解决问题。如果您查看Chaim Eliyah提供的链接，则可以获得销售和支持上下文.http：//martinfowler.com/bliki/BoundedContext.html

现在没有理由销售产品，支持产品在数据库中看起来应该相同。重要的是，如果支持人员想要添加属性（例如"低质量"），它可以这样做，而销售人员可能不需要该属性。此外，销售应用程序的停机时间可能不会影响您的支持应用程序。

也就是说，实体并不关心它们的存储位置。如果您已经拥有庞大的产品数据库，则当然可以基于同一数据库为不同的边界上下文构建实体。要记住的是，数据库表与实体不同。实体是您的业务/应用程序所需要的。数据库正是存储东西所需要的。

也就是说，如果可以的话，分开。如果这不可行，请尝试定义所有权。如果每个人都同意产品是销售定义的产品，并且支持可以有一个"产品概况表"来增强产品，那么您的生活就会轻松得多。这样，就可以避免每个界定上下文中的冲突更改。（还有一个后续问题是支持只能读取产品，但不能写入）。表前缀可能有助于明确这一点。

这个问题已经存在于 2 个相关的有界上下文中。到 10 点，如果多个上下文尝试写入同一个表，您将遇到噩梦。