domain-driven-design - DDD : one bounded context or two?

Question

假设我为我的客户建立了一个系统，允许赌徒维护一个赌注组合并随着时间的推移跟踪他们的 yield /损失。
该系统支持许多复杂的领域逻辑 - 投注不同的运动，将胜利滚动到其他投注等。

接下来，我的客户想要支持提示者的想法。提示者实际上并不赌博，而是他们
创建“提示表”，这是他们关于下注的提示。提示表可以是不同的
种类 - 有些可以包括任何可投注赛事的提示，其他仅提供有关赛马的提示，等等。
我的客户希望系统以与跟踪提示者表现相同的方式跟踪提示者的表现
赌徒，能够比较不同类型的推销员内部和之间的表现(例如，谁是最好的赛马推销员？他们通常比足球推销员表现更好吗？)

现在，赌徒和推销员之间的领域语言完全不同，还有额外的
赌徒投资组合不存在的提示表分类。这表明这些是单独的有界上下文。
但是，有很多共享逻辑，因为它们都随着时间的推移跟踪性能。

所以我的问题是:

这些真的是独立的有界上下文吗？我对在赌徒上下文中添加分类持谨慎态度(感觉就像一个滑坡)。

如果它们是不同的上下文，我应该:

在它们之间共享性能跟踪逻辑(即共享 DLL、jar 等)？这在感觉错误的上下文之间创建了紧密的实现耦合。

将性能跟踪逻辑留在赌博有界上下文中，将分类逻辑放在提示者边界上下文中，并让它要求赌博上下文跟踪性能？在这种情况下，提示者上下文似乎会将命令发送到赌博上下文，这再次让人感觉不对(我对事件更满意)。

做其他事情......某种在两个上下文之间进行通信和关联的组合层？

澄清

赌徒的投资组合和提示者的提示表几乎相同 - 唯一的区别是提示表可以分类(例如赛马、足球等)。

绩效跟踪是关于衡量投资组合/提示表的损益。

Answer 1

如果您看到两个明显独立的模型，只有技术重叠，那么我同意您有两个 BC。但是，请注意，拥有多个 BC，尤其是当它们需要通信时，可能会有点“昂贵”。使用模块要“便宜”得多，这就是为什么你不应该轻易决定拥有多个 BC。

blue book ，第 4 部分(战略设计)，第 15 章(蒸馏)，介绍了非常适合您的场景的通用子域的概念。性能计算可以被视为一个通用子域，因为虽然它们对模型的整体功能至关重要，但它们可以被隔离到一个可供两个 BC 使用的库中。这是一种用于提炼模型并保持技术问题抽象的模式。您不需要在 BC 之间实现复杂的消息传递或 RPC 通信，只需使用具有意图显示接口(interface)的共享库即可。