DDD：一个有限的背景或两个？

Question

假设我为我的客户建立了一个系统，允许赌徒保持投注组合并跟踪他们的收益/损失。 该系统支持许多复杂的域逻辑 - 对不同的体育投注，将胜利推到其他投注等。

接下来，我的客户希望支持提示者的想法。提示者实际上并不赌博，而是他们 创建“提示表”，这是他们下注的提示。尖端片可以是不同的 种类 - 一些可以包括任何可下注的事件的提示，其他人只提供有关赛马的提示，等等。 我的客户希望系统跟踪提示者的性能，就像跟踪其性能一样 赌徒，还能够比较不同类型的推特内部和之间的表现（例如谁是最好的赛马推特？他们一般比足球推销员表现更好吗？）

现在，域名语言在赌徒和提示者之间完全不同，还有其他的 赌徒投资组合中不存在的提示表分类。这表明这些是独立的有界背景。 但是，有很多共享逻辑，因为它们都会跟踪性能。

所以我的问题是：

1. 这些是真正独立的有界背景吗？我很担心在赌徒的背景下添加分类（感觉就像一个滑坡）。
2. 如果他们是不同的背景，我应该：
   • 在它们之间共享性能跟踪逻辑（即共享DLL，jar等）？这在感觉错误的上下文之间创建了紧密的实现耦合。
   • 将性能跟踪逻辑留在赌博有界的上下文中，将分类逻辑放在tipster bounder上下文中，让它让赌博上下文跟踪性能？在这种情况下，似乎推特上下文会向赌博上下文发送命令，这又感觉不对（我对事件感觉更舒服）。
   • 做其他事情......某种组合层在两种情境之间进行沟通和关联？

澄清

赌徒的投资组合和推特的提示表几乎完全相同 - 唯一的区别是提示表可以分类（例如赛马，足球等）。

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

Answer 1

1. 如果你看到两个明显分开的模型，只有技术重叠，那么我同意你有两个BC。但是，要注意有多个BC，特别是当他们需要通信时，可能有点“昂贵”。使用模块要“更便宜”，这就是为什么你不应该轻易决定拥有多个BC。

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

Answer 2

这显然是（至少）2个有界上下文（BC）的情况，他们有不同的领域语言这一事实​​是最大的线索。

如果我说得不错，性能跟踪是一个领域概念，可能它应该是BC本身。您可以定义用于常见跟踪和特定跟踪（用于提示者）的接口 - 在通用接口类型的项目中 - 将由来自其他BC的实体实现。因此，PerformanceTracking BC将不关心具体的赌徒或推荐人，其他BC也不会与特定的性能跟踪器耦合。

是的，您需要同步BC，域事件才是出于此目的。它并不是很简单，但如果仔细完成它并不复杂，你可以从松散耦合的代码中获得巨大的好处。

Answer 3

我认为他们是两种不同的背景，你也这么认为，对吗？

我个人会使用赌博环境中的域事件来生成效果跟踪信息。代码仍然松散耦合（因为逻辑只取决于域事件）。

当然，您可以在其间创建不属于任何这些jar / dll的适配器。即在context1中订阅域事件的东西，调整信息，然后在context2中调用东西。通过这种方式，您可以在上下文之间获得100％的透明度。

Answer 4

我可能同意迈克的观点，即性能跟踪听起来像是一个有限的上下文。这似乎是更明显的边界。

Betters和Tipsters可能会对同一有界上下文或不同有界上下文的不同聚合进行操作。根据你对语言的看法，以及项目的演变，我倾向于选择后者。