1

所以我是 DDD 的新手，我正在尝试正确设计一个应用程序。但是我在识别聚合根时遇到了一些困难。

我的需要或多或少是一棵树

*Customers
*Each customer can have 0 or more licenses
*Each license can have 0 or more courses
*Each course can have 0 or more lessons
*Each lesson can have 0 or more slides and videos

最后，我的测验/测试几乎可以链接到任何东西，甚至是课程视频中的某个时间。

不管我怎么想，我只知道 Customer 将是包含 [Customer, License, Course, Lesson, Slide, Video] 的聚合的聚合根

但这是一个相当大的聚合，我知道应该避免大聚合。

然后，测验将是问题、答案等的集合。作为第二个问题，我可能会问链接应该是什么样子？因为假设我想在 4 分钟后在视频中弹出一个测验。那么我的测验需要链接到该视频并存储时间。但该视频是另一个聚合（在客户、许可证、课程、课程下）的深处，不应以持久的方式直接从该测验聚合中链接。

那我该如何解决。我已经订购了我的大 DDD 书，但暂时不会在这里，如果我能在此之前理解这一点，那就太好了！

我没关系，但我使用 .net c# mvc，带有 ef5 和存储库模式。

4

2 回答 2

2

为了简化事情，您应该使用 CQRS，即使用不同的模型进行“编写”和查询。这意味着我们有 2 个案例 1. 创建和更新业务对象（实体） 2. 从业务对象生成简化模型以允许简单查询

使用这种方法意味着您可以专注于对客户、许可证、课程、课程进行严格建模，目的是为真实行为和它们之间的关系建模。

在这里很容易陷入以数据为中心的方法，其中客户被视为许可证的容器，而许可证又是课程等的容器。很明显（即使没有太多信息）这些实体是聚合根而不是容器。

将课程组织成根据许可证组织的课程可能更合适。这意味着课程实体与一些课程实体相关联，因此课程实际上没有课程。它有一个名字、一个教学大纲等。课程、教授、学生被“附加”到课程中，但不是课程的一部分。

客户实体对客户进行建模。当客户购买了一些许可证时，他就有权访问与该许可证相关的课程。再一次，客户没有许可证。因此，您需要在此处对客户和许可证之间的关联进行建模。这样做时，请考虑 License 的哪些详细信息取决于客户的哪些详细信息（它们可能不是，因为它们是完全不同的东西，所以基本的 (CustomerId,LicenseId) 就足够了）。当然，这些都是简单的建议，因为我并不完全了解该领域。

要点是，您必须深入了解客户、许可证等对域的含义，并抵制以“明显”方式查看事物的冲动。DDD 建模并不难，但它非常棘手，因为你真的不能肤浅。

于 2013-04-12T11:13:45.037 回答
1

您应该在业务不变量之后定义聚合。

看看弗农关于聚合设计的文章。
要关联不同的聚合，您可以使用共享标识符，这也消除了延迟加载的需要。

但是，您还应该考虑是否必须设计不同的有界上下文。与您的领域专家交谈，解释每个有界上下文都与对此事的特定观点有关。

于 2013-04-12T10:18:45.120 回答