在DDD中，据我所知，它可以帮助或指导您如何构建复杂的应用程序。现在在应用程序中，您应该识别您的有界上下文。假设您有超过10个BC。
我在某处阅读（原谅我，我不能给出任何链接），对于复杂的应用程序来说，拥有一个大数据库是不理想的。它应该为每个BC分开。如果这是更容易的路线。如果每个BC都有自己的数据库，应如何构建应用程序。
我尝试在github上搜索但找不到。
答案 0 :(得分：5)
这取决于它们只共享相同的数据库还是某些表 - 即数据。
共享数据库而不是表格可以完全没问题。除非您的目标是可伸缩性，并打算使BC的可独立部署和可运行的单元（如微服务），在这种情况下，它们应该有自己的数据存储实例。
我发现2个或更多有界上下文共享的数据库表还有一些缺点：
紧耦合。我们有不同BC的原因是它们代表了可能以自己的方式发散的不同域空间。改变其中一个BC的概念可能会影响基础表，迫使使用该表的其他BC也发生变化。你应该在柔软的地方获得刚性。由于存在多种可能的变化来源，您可能还会在数据中出现不一致或“漏洞”。
并发。在高度并发的系统中，某些实体和下面的表受到强烈争用。有界上下文是通过分离不同类型的写入来减轻负载的方法之一，但只有在它们在一天结束时不锁定相同数据时才有效。对于非CQRS系统中的读取也是如此，在这些系统中，它们查询完成写入的同一数据库。
ORM友善。大多数ORM都不允许您在没有大量卷积和解决方法的情况下从同一个数据库表映射到2个或更多类。
如果每个BC都有自己的数据库，应如何构建应用程序。
在某种程度上（例如，可能包括UI层），就像您有多个单独的应用程序一样。如果您有精确的问题，请更具体。
答案 1 :(得分：4)
每个有界上下文具有这个垂直切片的想法是每个BC与每个其他BC的关系以及它们之间的通信应该基于领域知识而不是持久性技术的技术优点来考虑和设计
如果您在2个不同的BC中有 Customer ，则会导致一种类型的actor模式情况。如果 Support BC在 Sales BC中创建新客户时需要了解该客户，那么 Sales > BC需要连接到 Support BC上的已知接口，并将此新信息传递给它。一个域与另一个域交谈。当来自不同部门的人们相互交谈时，它会非常密切地模拟现实生活中的事物。
如果您共享一个大型数据库（您在这里谈论定制的企业软件，那么在野外就不会有很多示例）那么诱惑就是绕过域层中捕获的所有领域专业知识和在另一个BC的数据库中插入。事情很快变成了大泥球。
令人惊讶的是，我在现实世界中经常看到这种事情，我认为这是非常糟糕的做法。
答案 2 :(得分：3)
它取决于它们是自己的数据库的原因。有界上下文的想法是，您有一组相互关联的实体并一起解决问题。如果您查看Chaim Eliyah提供的链接，您可以获得销售和支持背景。http://martinfowler.com/bliki/BoundedContext.html
现在没有理由将产品用于销售，而支持产品在数据库中应该看起来相同。重要的是，如果支持者想要添加一个属性（比如说＆＃34;低质量＆＃34;）它可以这样做，而销售可能不需要该属性。您的销售应用程序的停机时间也可能不会影响您的支持应用程序。
说实体并不关心它们存储的位置。如果您已经拥有庞大的产品数据库，那么您当然可以基于同一个数据库为不同的有界上下文构建实体。要记住的是数据库表与实体不同。实体是您的业务/应用程序所需要的。数据库正是存储事物所需要的。
那就是说，如果可以，请分开。如果这不可行，请尝试定义所有权。如果每个人都同意产品是销售定义的产品，并且支持可以产生＆＃34; productfactsheetTable＆＃34;那么您的生活将变得更加轻松。增加产品。这样就可以避免每个有界上下文中的冲突发生冲突。 （另外一个后续是支持只能读取产品但从不写入）。表格前缀可能有助于明确这一点。
这个问题已经存在于2个相关的有界上下文中。如果多个上下文尝试写入同一个表，那么到10岁时你就会有一场噩梦。