4

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

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

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

所以我的问题是：

  1. 这些真的是独立的有界上下文吗？我对在赌徒上下文中添加分类持谨慎态度（感觉就像一个滑坡）。
  2. 如果它们是不同的上下文，我应该：
    • 在它们之间共享性能跟踪逻辑（即共享 DLL、jar 等）？这在感觉错误的上下文之间创建了紧密的实现耦合。
    • 将性能跟踪逻辑留在赌博有界上下文中，将分类逻辑放在提示者边界上下文中，并让它要求赌博上下文跟踪性能？在这种情况下，提示者上下文似乎会将命令发送到赌博上下文，这再次让人感觉不对（我对事件更满意）。
    • 做其他事情......某种在两个上下文之间进行通信和关联的组合层？

澄清

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

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

4

4 回答 4

3

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

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

于 2012-10-26T16:26:11.537 回答
2

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

如果我理解正确，性能跟踪是一个领域概念，可能它应该是 BC 本身。您可以在通用接口类型的项目中定义通用跟踪和特定跟踪（用于提示者）的接口，这些接口将由其他 BC 的实体实现。因此，PerformanceTracking BC 不会关心具体的赌徒或提示者，并且其他 BC 不会耦合到特定的性能跟踪器。

是的，您将需要同步 BC 和域事件正是为此目的。它并不完全简单，但如果仔细完成它并不那么复杂，并且您会从松散耦合的代码中获得巨大的好处。

于 2012-10-28T08:13:34.047 回答
1

我确实认为它们是两种不同的背景，你也这么认为，对吧？

我个人会使用赌博环境中的领域事件来生成性能跟踪信息。代码仍然是松耦合的（因为逻辑只依赖于领域事件）。

您当然可以在它们之间创建不属于任何这些 jars/dll 的适配器。即订阅context1 中的域事件，调整信息，然后调用context2 中的东西。这样，您就可以在上下文之间获得 100% 的透明度。

于 2012-10-26T14:26:59.747 回答
1

我可能同意 Mike 的观点，Performance Tracking 听起来像是他自己的有界上下文。这看起来像是更明显的边界。

Betters and Tipsters might act on different aggregates of the same bounded context or different bounded contexts. I'd be inclined to choose the latter, according to what you say about the language, and about project evolution.

于 2012-10-29T13:42:40.350 回答