问题标签 [bounded-contexts]

我的意思是 - 物理上，在代码中。命名、命名空间、文件夹、程序集、数据库的组织。

有界上下文应该如何交互？

例如，随意使用经典的电子商务业务领域。

在我的领域中，我有 2 个与此问题相关的有界上下文：

1. 采购 - 客户订购服务的地方
2. 履行 - 将服务分配给供应商以完成

要求客户在整个订单生命周期的任何给定时间都可以编辑订单。

如果客户从订单中删除了一项服务（即在购买环境中），如果该服务已经分配给供应商以执行（但尚未执行），那么该服务也必须在履行环境中删除。

这里有几个选项，我想听听社区的意见：

1. 我的上下文错误，因为这将创建一个跨上下文事务。
2. 我在这里可能不需要事务一致性。当然，这是由业务利益相关者决定的，这引出了两个问题：实施选项是什么？我如何向业务利益相关者提出这个问题？
3. 这是对“无跨上下文事务”规则的可接受的违反。

编辑

这一切都发生在一个进程中，因此中间事务失败的可能性非常低。

我最近一直在采用领域驱动设计原则，但是在实现有界上下文以及上下文和/或其他系统之间的集成时遇到了一些麻烦。

例如，采用以下系统：

仓库/库存系统实体将包括具有诸如“数量”、“位置”等属性的“产品”

在线订购系统实体将包括“Order”、“OrderLine”和“Basket”。它是否也有自己的 Product 实体，该实体具有诸如“价格”之类的属性？

订购系统的一个明确业务规则是不能为缺货的产品下订单，但此信息在库存管理系统中。据我了解，这些是一些可能的实现方式：

1. 当订单被验证时，Order 对象调用库存系统中的服务来检查每个所需产品是否有足够的库存。然而，调用另一个系统的应用程序服务的域感觉有些不对劲，而且如果所有系统都这样做，这将导致一切都紧密耦合和交织在一起。

2. Ordering System从Stock Keeping System的数据库中读取：Ordering System中的Product实体映射到Ordering System中的Product表和Stock Keeping系统中的Product表的join，或者Ordering System中的Product实体包含另一个名为 StockKeepingProduct 的实体具有来自 Stock Keeping System 的值。这将很容易执行验证，但必须确保订购系统永远不会写入库存系统的数据库。

3. 库存数量被非规范化到订购系统的数据库中，并且每当库存管理系统的库存发生变化时，它都会向订购系统发送一条消息以更新其库存。

可能在内心深处我知道我应该做 3，但我不确定我们是否已经准备好处理如此多的冗余数据和可能的不一致。你对1和2有什么看法？或者你有什么其他建议吗？

我对如何定义它们之间存在共同关注点的有界上下文以及如何用域实体表示这一点感到困惑。

例如：客户在客户上下文中有许多产品公司在公司上下文中有产品列表

所以客户是通过客户上下文来管理的，公司是通过公司上下文来管理的

鉴于上下文位于不同的模块中。

如果我想在产品中提供公司的详细地址，应该如何处理？

我是在包含客户的模块中引用包含公司上下文的模块，还是在客户上下文中创建一个公司实体，专门用于与客户交互时使用？

谢谢

我试图了解实体如何在多个有界上下文中运行。

给定公司的员工。在（例如）人力资源上下文中，此人有姓名、姓氏、地址、工资参考号和银行帐户。但在会计上下文中，所有相关的只是工资参考号和银行账户。

您在 HR 上下文中是否有一个 Employee 实体，SalariedEmployee在会计上下文中是否有一个 Value-Type（例如 ）？

SalariedEmployeeclass (??) : 员工的值类型

限界上下文中的 HRService 是否返回此信息？还是在这两种情况下都使用 Employee 类？

我正在尝试使用 Java Modeling in Color 中的Party Place Thing和Role原型。

此外，我还尝试合并 DDD 最佳实践，现在假设我们有 1 个人在我的应用程序中扮演 2 个角色，比如客户和患者。

客户角色用于 CRM 有界上下文，患者角色用于医院管理有界上下文。

我的角色类可以使用弱 id 访问 Person 详细信息，这是一个可以唯一表示 Person 的值对象，可以在此处找到此方法的详细信息。

现在，在 Party Place Thing 原型中，指定的职责之一是能够列出派对所扮演的角色。

鉴于角色存在于不同的限界上下文中，如何实现这一点？

因此，理想情况下，客户和患者不应与 Person 存在于相同的有界上下文中

我们正在学习 DDD 并评估其在由遗留系统和数据存储支持的系统中的用途。

我们一直在使用 Anti-Corruption Layer、Bubble Context 和 Bounded Context 却不知道它们，这种方法对我们来说似乎很实用。

但我们对识别方法和身份相关性并没有把握和信心。旧数据存储没有主键，而是使用复合唯一索引来标识信息。

我们目前正在将模型创建为应该是实体的值对象（希望为每个对象添加“Long id”字段），或者我们很少使用唯一索引中使用的属性组合作为 id 字段。我们似乎很清楚实体模型应该有 id 字段。

以下是我的具体问题：

• 我们希望我们闪亮的新实体在理论上具有“Long id”字段。现在不添加该字段是否可以，因为这没有给我们任何价值，因为后端数据存储不会填充或理解该字段？
• 是否可以以 DDD 方式存储标识信息并在稍后的某个时间对其进行重构，希望数据存储能够满足我们的需求。
  • 如果是这样，从实体中抽象标识是好的方法（我的意思是可识别接口，还是每个实体的 KeyClass？-这里需要任何好的建议..）
• 这个问题可能超出了 DDD 的范围，但我想知道识别重构是否会对系统的多个层造成影响（例如，REST api 可能从/entity/id_field/id_field/id_field 更改为/entity/new_long_id）

和其他问题：

• 我们如何将遗留信息用于我们不断发展的完善的域模型，同时减少识别问题的痛苦？

• 或者在项目生命的任何时候都希望我们的域拥有Long id是不好的和没有价值的？

• 我们如何重构身份管理？

更新：

• 身份管理是 DDD 的重要方面，还是可以重构的基础设施方面，所以我们不应该花更多时间在上面？

我有 3 个使用具有 REST 接口的不同数据库的独立服务：

• 第一服务：客户信息
• 第二项服务：关于客户交易的信息
• 第三项服务：有关客户文档的信息

问题：每个客户都有一个状态，应该根据他的交易和文件进行评估。

哪个服务应该负责这个评估，我应该如何实现其他服务之间的编排？

我正在重组我当前的项目，以更好地符合 DDD 最佳实践。

作为此设置的一部分，管理任务允许基于配置文件/算法组合（重新）引导某些域对象/聚合。我对此有一个很好的用例，它确实要求它成为实时系统的一部分，而不是仅用于测试（例如文本固定装置）。

我正在努力如何在 DDD 上下文中最好地模型重构：

基本上：构建器/引导程序是属于与域对象相同的有界上下文的基础设施服务吗？这会感觉很自然吗？我看到的流程是管理员使用特殊的管理应用程序服务访问这些功能，该服务反过来调用构建器来完成他们的工作。

另一方面，这个管理功能感觉像是系统的一个独立部分，所以也许我不应该用支持引导的方法污染域对象（或其工厂）。IOW：这可能意味着一个单独的有界上下文，具有完全不同的（无逻辑）域模型，纯粹用于持久化到数据库。然而，这对我来说并不是很干燥，因为我最终可能会定义两次模型（每个 BC 一次）

解决此问题的最佳方法是什么？

我使用 NServiceBus 创建了一个传奇，它请求外部服务以获取客户信息并超时。超时后，传奇检查外部服务是否有响应。作为回应，我有相应客户的数据，现在我必须检查相应客户是否存在于我们的系统中（如果他不存在 - 我必须创建他），然后我必须创建一些额外的审计实体来引用那个客户（如果我有创建它们所需的所有信息）。

我想知道我应该如何检查特定客户是否存在以及何时不存在如何创建他。

到目前为止，我有几个想法：

• 从消息处理程序内部调用 WCF 服务（检查、创建）

• 通过 NSB 向客户有界上下文发送消息并等待带有 ID 的响应。