2

我发现了一些关于建模多对多关系的问题，但没有任何东西可以帮助我解决当前的问题。

设想

我正在建模一个具有Users 和Challenges 的域。挑战有很多用户，用户属于很多挑战。挑战存在，即使他们没有任何用户。

在此处输入图像描述

很简单。我的问题变得有点复杂，因为用户可以在挑战中排名。我可以将这些信息存储在挑战中，作为一组用户和他们的排名——同样不是太难。

问题

如果我想查询用户在挑战中的个人排名（不获取挑战中所有用户的排名），我应该使用什么方案？在这个阶段，我不在乎如何调用数据访问，我只是不想在只需要一个时返回数百个排名数据点。

我也想知道在哪里存储排名信息；感觉就像它取决于用户和挑战。这是我考虑过的：

  1. 显而易见：实例化 a 时Challenge，只获取所有排名信息；较慢但有效。

  2. 制作一个复合UserChallenge实体，但这感觉像是违背了领域（我们不会到处谈论“用户挑战”）。

    在此处输入图像描述

  3. 第三个选项？

我想选择第二个，但我没有足够的信心知道这是否真的是 DDD 方法。

更新

我想我可以称之为UserChallenge更合适的领域，比如Rank，UserRank或者什么？

4

2 回答 2

1

这里的 DDD 方法是根据领域进行推理，并与您的领域专家/业务分析师/任何人讨论这个特定点以改进模型。不要忘记您的实体名称是通用语言的一部分，需要非技术人员理解和使用，因此“UserChallenge”可能不是他最合适的术语。

我首先要做的是尝试确定该“中间实体”是否值得在域模型和无处不在的语言中占有一席之地。例如，如果您正在构建一个网站并且有一个专门的排名页面，用户可以在其中看到所有挑战的列表以及相关排名，那么排名很可能是应用程序中的关键问题，排名实体将是代表这一点的好选择。您可以与您的领域专家交谈，看看排名是否适合它，或者换个名字。

另一方面，如果没有证据表明需要这样的实体，我会坚持选项 1。如果您担心性能问题，有一些方法可以减少关系的多重性。埃里克·埃文斯（Eric Evans）称其为协会的资格（DDD，第 83-84 页）。从技术上讲，这可能意味着挑战有一个地图 - 或以用户为键的排名字典。

于 2012-05-08T08:57:06.877 回答
0

我会选择选项 2。你不必“到处谈论用户挑战”，但你必须四处抓住所有用户以应对给定的挑战并按排名对它们进行排序，这个模型为你提供了一个很好的办法！

于 2012-05-04T17:24:37.960 回答