您是否应该为每个有界上下文设置一个数据库到规则 - 所有设置或分离数据库？

Question

在DDD中,据我所知,它可以帮助或指导您如何构建复杂的应用程序.现在在应用程序中,您应该识别您的有界上下文.假设您有超过10个BC.

我在某处阅读(原谅我,我不能给出任何链接),对于复杂的应用程序来说,拥有一个大数据库是不理想的.它应该为每个BC分开.如果这是更容易的路线.如果每个BC都有自己的数据库,应如何构建应用程序.

我尝试在github上搜索但找不到.

Answer 1

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

如果您在 2 个不同的 BC 中有一个客户，则会导致一种演员模式情况。如果在销售BC 中创建新客户时，支持BC 需要了解新客户，那么销售BC 需要连接到支持BC上的已知接口并将此新信息传递给它。一个域与另一个域通信。当来自不同部门的人们相互交谈时，它非常接近地模拟了现实生活中事物的运作方式。

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

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

Answer 2

这取决于它们只共享相同的数据库还是一些表 - 即数据.

共享数据库而不是表可以完全没问题.除非您的目标是可伸缩性,并打算使BC的可独立部署和可运行的单元(如微服务),在这种情况下,它们应该有自己的数据存储实例.

我发现由2个或更多有界上下文共享的数据库表有一些缺点:

• 紧耦合.我们有不同BC的原因是它们代表了可能以自己的方式发散的不同域空间.改变其中一个BC的概念可能会影响基础表,迫使使用该表的其他BC也发生变化.你应该在柔软的地方获得刚性.由于多种可能的更改源,您可能还会在数据中出现不一致或"漏洞".

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

• ORM友善.大多数ORM不允许您从同一个数据库表映射到2个或更多类,而没有大量的卷积和变通方法.

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

在某种程度上(例如,可能包括UI层),就像您有多个单独的应用程序一样.如果您有精确的问题,请更具体.

Answer 3

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

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

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

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

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