问题标签 [bounded-contexts]

我正在从事 DDD 项目，目前我专注于两个有界上下文，Orders和Warehouse。

让我困惑的是以下情况：订单跟踪所有已下订单，仓库跟踪所有可用库存。如果用户为某个产品项目下一个订单，那将意味着该产品在仓库中少一件。我过于简化了这个过程，所以请多多包涵。

由于两个域模型被放置在不同的 BC 中，我目前依赖于最终的一致性，即。一件商品售出后，最终会从仓库中取出。

不幸的是，这种情况会导致问题场景，即另一个用户可以同时对同一项目进行另一个订单，并且在最终一致性启动之前它会显示为可用。这是领域专家无法接受的。

所以IMO我有两个选择

• 将订单和仓库（至少是关于产品库存、仓库中可用单位的部分）合并到一个 BC
• 让订单 BC（或微服务，如果您愿意）依赖于 Warehouse BC（微服务），以便提取可用的实时产品单元

哪个选项实际上遵循 DDD 模式？还有其他出路吗？

我的软件是一种社交网络，除其他功能外，成员还可以在其中安排他们之间的一些会议。

我选择出现这三个有界上下文（DDD）：

• IdentityAndAccessContext，主要处理用户身份验证/授权。
• SocialContext，处理会员和有关他们的所有社交信息；他们的兴趣等，类似于经典的社交网络。
• MeetingsContext，处理一些成员之间的会议。我们正在谈论作为创作者/参与者/参与者等的翻译价值对象。

基本上，在MeetingsContext中，会议的创建用例需要一个成员列表（以便邀请其中一些成员），基本上是通过一个 Web 表单，用户在该表单中选择一些提供一些有趣但轻松的社交信息的成员。

您可能会发现，SocialContext显然是以社交方式掌握成员数据。

我应该在SocialContext中创建一种开放主机服务，为用例返回一些相关的成员数据吗？

它将由MeetingsContext直接使用（REST 协议），如果需要，可能通过反腐败层。

或者我应该缓存甚至可能在MeetingsContext中复制相关成员的数据以改进它的自包含方面？

使用缓存解决方案，缓存将以最终一致性的方式同步。

在这种情况下有什么好的做法？

我有一个域，其中存在可以相互分配任务的团队成员。我有 2 个有界上下文：

TeamBC：团队成员及其信息的管理。

TaskBC：任务及其分配的管理。

TeamBC 在上游，TaskBC 在下游。TeamBC 中的“成员”概念是 TaskBC 中的“接收者”概念。任务的接收者是任务被分配到的团队成员。

我使用同步集成，在 TeamBC 中使用 rest api，在 TaskBC 中使用 ACL。收件人是 TaskBC 中的 VO。

我的问题：

与rest api集成时（不使用BC之间的消息传递），下游上下文是否必须复制上游的任何数据？在我的情况下...... TaskBC 是否必须将任何来自 TeamBC 成员实体的数据存储在其数据库中？

考虑有一个要为其创建有界上下文的域。但是，不应在此域中保留任何内容。应该只存在纯粹的基于任务的逻辑，并且不会更新假设的域模型。

我看不到在这样的领域中应用实体模式的方法，在这种情况下我只想到服务和价值对象。我现在想知道，以下哪一项陈述是正确的：

1. 这是不应该应用 DDD 的子域
2. 问题在于战略设计，永远不应该将此类子域提取为单独的有界上下文
3. 可以只使用服务和值对象创建域模型

我有一个关于分解成微服务的问题。假设我们有 2 个微服务：User和Product。假设我们现在需要向系统添加类别。更具体地说，产品具有一个或多个类别（例如产品红色微型法拉利属于玩具和汽车类别），并且用户可以具有她喜欢的类别（例如玩具和鞋子）。现在，当我们检索完整的产品列表时，我们希望对它们进行排序，使得属于首选用户类别的产品位于顶部。

基本上是有一个在微服务之间共享的概念（在这种情况下是类别）。如何在微架构环境中对此进行最佳建模？我看到两个解决方案：

解决方案1：

• 制作一个单独的“类别”微服务来管理类别的 CRUD
• 在产品服务中有一个 API 调用将类别 ID 链接到产品
• 在用户服务中有一个 API 调用将类别 ID 链接到用户
• 在产品服务中，我们有一个 API 调用来获取按偏好订购的产品。为了完成这项工作，产品服务需要调用用户服务来获取用户类别（或监听用户服务发出的事件）

解决方案2：

• 制作一个单独的“类别”微服务来管理类别的 CRUD

• 类别服务还有一个 API 调用来将产品 ID 链接到类别

• 类别服务还有一个 API 调用来将用户 ID 链接到类别

• 在产品服务中，我们有一个 API 调用来获取按偏好订购的产品（为了使这项工作正常工作，产品服务需要调用类别服务来获取用户和产品类别（或监听事件）

两种解决方案的优点/缺点是什么？

我有一个包含多个子域的 ERP 项目。它不使用 CQRS 或域事件。

我有两个子域；客户关系管理和会计。客户概念需要在两个子域中进行不同的建模。CRM 需要知道公司的规模（员工人数），而不是税号。会计需要知道税号而不是大小。两个子域都需要公司名称。

我正在考虑将 CRM 客户和会计客户建模为实体。但是，每当 CRM 用户创建新客户时，还需要创建会计客户实例。如果报告需要来自两个子域的信息，那么查询会变得比当您拥有包含所有信息的单个实体时更加复杂。

这是要走的路吗？有没有更好的办法？在不使用域事件的情况下拥有多个子域是否有意义？

关于整合有界上下文的问题。 例如。我organization AR在indentity BC. 而courier service AR在logistics BC. 它们必须连接。

organization AR由组成：

• 组织 ID
• 姓名
• 税法
• 合法地址
• ...

courier service AR由组成：

• CourierServiceId
• 姓名
• 交通优先
• 评分
• ...

客户在一个请求中发送所有这些信息（姓名、税码、法律地址、TransportationPriority、Rating）。

问题：

1. 我应该在哪个应用程序中提交创建两个 AR 的请求？
2. 我应该如何创建两个 AR？在第一个 BC 中创建第一个 AR 后，我应该如何从第二个 BC 创建第二个 AR？

我面临的问题：

起初我想在organization AR创建通知logistics BC和创建时发布域事件courier service AR。但是当我在第一个 BC 中发布域事件时，我必须使用语言概念作为TransportationPriority, Rating（在第二个 BC 中创建 AR 所需的）。但这种语言概念并不属于公元前。但是它们被用于其中。据我所知，这是错误的。

那么我该如何解决我的问题呢？对不起，我的英语不好。非常感谢。

我一直在阅读有关 DDD 和微服务的文章。通过 CQRS 部分的用例开始原型设计。用例是一个体育足球应用程序，其中包含视频、新闻、比分和主页。在此，我已经确定了域和有界上下文，它们是

1. 消息

2. 视频

3. 分数

4. 主页

首先，3 个域完全相互独立。

现在，主页域要求。1. 乐谱部分 2. 视频部分 3. 内容部分

内容部分：它有自己的数据库

视频部分：它将使HTTP调用视频服务并获取数据

Score 部分：它将通过 HTTP 调用 Score 服务并获取数据

我的问题是主页域。我发现它与其他服务高度耦合并且不是独立的。

如何设计主页域？

好的，我很欣赏标题听起来很奇怪。事件应该总是针对已经发生的事情，例如 OrderCreated、ParcelShipped 等。

但是，我想知道是否有人对以下问题有任何想法。

考虑一个对人员及其工作进行建模的 HR 应用程序。为简单起见，一个人可以拥有一堆工作，并且可以在某个日期结束。这个人有一个 EndJob 操作，它需要一个 endDate。

如果 endDate 在未来，领域事件会是什么？

JobEndedEvent（这不是真的）

JobEndDateAddedEvent（这是相当技术性的）

其他有界上下文中的消费者将有兴趣知道作业将要结束，但也可能希望在作业结束时也得到通知。我觉得后者应该是消费者的责任，而不是来源的责任。

欢迎任何想法......谢谢。

我正在努力设计正确的 akka 集群中 2 个独立的 akka 微服务/有界上下文之间的通信。

假设我们每个节点在集群中有 2 个微服务。
两种微服务都基于 akka。

对我来说很清楚，特定有界上下文中的通信将通过从参与者到参与者或从节点 1 上的参与者发送消息到节点 2 上的参与者来处理（如有必要）

问：但是可以在单独的 akka 应用程序之间使用类似的通信吗？例如 boundedContext1.actor --message--> boundedContext2.actor

或者应该通过更清晰的界限来完成：在bc1中引发一个事件- 发布到代理并在bc2中读取事件？

//编辑当前我们已经实现了一个服务注册中心，我们正在通过 Akka 流向服务注册中心发布事件。