问题标签 [bounded-contexts]

我对 DDD 的概念相对较新，并且发现有很多示例可以解释如何为相对简单的场景定义有界上下文，但似乎没有涵盖的一个领域是主数据和参考数据。

我所指的参考数据类型包括货币代码、国家代码和计量单位，它们将用于确保仅使用有效值。

我所指的主数据类型是客户和产品等实体，它们不需要不同的有界上下文拥有自己的实体视角。我知道在某些情况下，发票有界上下文中的客户实体与运输有界上下文中的客户实体不同，但出于这个问题的目的，我们可以假设发票和运输都需要完全相同的客户数据。

我的问题是在具有多个有界上下文（例如 ERP 系统）的应用程序中，主数据和参考数据是否应该在一个共同的有界上下文中定义，或者这些实体是否应该在每个有界上下文中重复，即使它们包含完全相同的数据?

我已经应用了域驱动设计的多界上下文原则，并且有 3 个不同的对象（在 3 个不同的域上下文中）指向数据库中的同一个表。正如 julie lerman 建议的那样，我有一个共享数据库模型，其中包含我的所有对象。此共享数据库模型用于代码优先迁移。我也有流畅的 api 配置，代表共享数据库模型上的外键关系和列约束。问题是，我是否应该让我的 3 个特定领域的上下文知道这些流畅的 api 配置。我想在每个上下文中验证我的对象图。我是否应该担心这些单独的域上下文中的字符串长度、所需等等？在 3 个单独的域上下文中的每一个上配置这些关系是否有必要/良好的做法？

我已经开始学习 DDD 的原理，目前正在尝试掌握有界上下文的概念。特别是，您如何决定它必须有多大（或小）？是的，我知道，尽可能小，尽可能大（根据 Vaughn Vernon 的说法）。

假设我要为博客建模。然后我可以说涉及 3 个有界上下文：1）首页（包含最新文章，未显示评论） 2）讨论（包括评论的单篇文章） 3）文章撰写者（我撰写文章的地方）。

但是，这感觉不对（无处不在的语言对所有人来说都是相同的），似乎我是从前端的角度来看的，并且仍在考虑视图模型或其他东西。

谁能指出我正确的方向？

使用数据库视图从多个有界上下文进行数据集成有什么问题吗？在我看来，这与进行 RPC 调用是一样的，因为数据库视图封装了数据的结构/细节。

因此，从我的阅读角度来看，我可以拥有来自多个有界上下文的数据库视图，这些视图可以协作来满足 UI 屏幕要求。它们是否紧密耦合，是的，但至少从我的理解来看，这与 Udi Dahan 所说的 IT/Ops 服务非常相似。

想法？

在使用户能够对服务进行支付的特定领域中，支付授权是一个不可或缺的部分，但鉴于技术上支付授权可以设计为一个独立的组件，它根据一些先决条件和传递的信息授权支付。

在这种情况下，支付授权应该是子域（支持域）还是支付子域中的有界上下文

这是一个关于在我们使用 ES 和 CQRS 和 DDD 的系统中引入新 BC 的理论问题。所以不会有具体的例子。

引入新的 BC-s 可能会出现有趣的问题，新的 BC-s 通过接收和发布域事件与旧的通信。这些问题的根源在于我们在事件存储中已经有了领域事件。当新的 BC 对那些旧的域事件做出反应时，它会以不同步和/或失序的方式进行。

例如，我们有一个旧的 BCA并且我们引入了一个新的 BC B。两者都发布我们称之为a和的领域事件b。例如，在新系统中，订单事项b1必须始终在之后a1，但在之前a2。当我们已经在事件存储中拥有a1, a2,序列时，我们能做什么？a3我们应该注射b1之后a1等等吗？这是一个巨大的事件存储的可行解决方案吗？将所有旧事件一一重播并做出反应肯定需要很长时间。我们如何通过处理新创建的b1事件来防止向客户发送电子邮件，该事件对 5 年前的主题作出反应？是否有防止此类问题的模式？

我正在努力理解使用 Doctrine 2 在来自不同有界上下文的两个实体之间实现关联映射的正确方法。假设有两个分别属于“用户”和“内容”有界上下文的“用户”和“发布”实体. “内容”上下文中还有一个“用户”概念，它通过多对一关联确定“帖子”的作者。因此，“内容”上下文中的“用户”只是一个包含用户 ID 的值对象。

我的问题是我应该如何使用 Doctrine 2 来实现这个关联？我有两个解决方案都有自己的问题：

解决方案 1：

解决方案 2：

在第一个解决方案中，“用户”上下文中的“用户”实体已在“内容”上下文中使用，这违反了关于 BC 彼此独立的 DDD 规则。第二种解决方案尊重 DDD 规则，但会影响数据库模式（通过外键约束删除“用户”和“帖子”表之间的数据库级关系）。

那么，实施此类关联的正确方法是什么？

我对ddd和有界上下文有疑问。

假设有两个有界上下文。在第一个中，聚合根是能够在网页上发布广告的客户。我想这属于他的行为，反过来他有一个 PublishAdvertisement() 方法。但是第二个有界上下文将广告作为聚合。由于广告属于客户的性质，这就要求广告具有客户属性。

客户和广告在系统和数据库中都是唯一的。

我的问题是：将广告的创建从客户委托给工厂或依赖注入是否可取？

编辑：

我感谢您的回答，并为缺乏信息而道歉。

依赖注入：

我想知道解决特定情况的最佳方法是什么。该公司有广告模板库存，如果模板有库存，则可以使用，如果没有，则将其租给某人。该公司计划拥有更多股票。如果客户想在这些模板中制作广告，他会选择一个模板，如果它有库存，一切都很好。阅读本文时，我假设应该有一个服务（域）CheckAvailability（模板），由于服务的性质，它不适合特定的聚合，因为它使用了多个带有验证的聚合并查询数据库。将来会有更多的 Stocks（一些是从其他公司租来的，可能是其他人的数据库），我打算使用依赖注入将这些 Stocks 添加到服务中而不更改实现。

有界上下文：

关于有界上下文和数据库。是的，有一个数据库对象和两个使用相同数据库对象的上下文。由于属于客户，订单有对客户的引用，看起来像这样

Order() 客户 customer(get; private set;)

///其他属性和方法

我将不胜感激通过链接、视频、书籍提供的任何其他信息，这些信息涉及到 2 个这样的上下文（客户->订单___1：M）与同一个数据库相关的含义。谢谢你。

我目前正在阅读有关 DDD 的信息，但我没有找到这个问题的答案。如果我们有一个具有多个有界上下文的大型应用程序，那么据我所知，我们应该实现每个 BC，因为它是一个单独的应用程序。因此，得出每个 BC 都有自己的 UI 和事件存储的结论是合乎逻辑的。我以前认为我们只有一个事件存储，因为根据一些文章（关于 CQRS），它是唯一的事实来源。这些陈述的唯一问题是它们缺乏上下文。那么事件存储是单个有界上下文还是整个应用程序中的单一事实来源？

我正在尝试首先使用多个上下文创建 EF 代码。StaffContext (HR) 的一个上下文是，ShippingContext。

1. 拥有多个上下文的想法有什么优势吗？因为我觉得构建起来很复杂。

2. 我们如何构建实体？在基本上下文或每个单独的上下文中定义所有？

3. 在这些上下文中，我需要访问 Staff 实体，当我尝试“更新数据库”时，它会给我一个错误，因为 Staff 实体已经存在于其他上下文中。我在不同的上下文中拥有相同的实体是错误的设计吗？

这就是我目前所拥有的：

提前非常感谢。