在使用事件采购时，是否有人可以就如何在分层域模型中组织实体，聚合根等提供任何建议？
项目有资产。资产是一种层次结构。每个资产都有一组数据（级别包含一组类别，类别包含一组项目等）。可能有10万个资产，反过来可能有10,000个子项目。
根据我对DDD的理解，会有一个聚合，其中项目是聚合根，因为没有资产和资产的级别不存在而没有项目等等。
这将导致项目中存在大量对象。这也意味着要添加一个案例，我必须在根上有一个方法，如CreateNewCase（资产，级别，类别，项目，案例）或CreateNewCase（itemId，case），如果每个项目都有唯一键。项目最终会非常庞大，并且包含处理应用程序中几乎所有实体的事件的方法。
任何帮助都将不胜感激。
答案 0 :(得分：2)
你几乎回答了你自己的问题 - 这个模型是不切实际的，而且每次从数据库中重新合成聚合根时需要加载数万个项目（除非采用复杂的延迟加载），这个模型会很慢。
没有＆＃34;＆＃34;不存在＆＃34;规则很少适用。我建议您在此处阅读汇总设计建议：http://dddcommunity.org/library/vernon_2011/ http://www.amazon.com/Implementing-Domain-Driven-Design-Vaughn-Vernon/dp/0321834577
答案 1 :(得分：2)
DDD完全是关于心态，在这种情况下，你会使用错误的心态。项目，资产，项目，类别等是域已知和使用的概念。聚合通常定义一个概念或用例。事件源只是一个实现细节：通过应用事件来改变状态，这些事件也是聚合的持久性。
但是，在开始之前，您需要正确识别聚合及其根。这是与编程语言，库，框架或实际实现（如事件源）无关的设计问题。
因此，您必须真正了解域及其用例所使用的概念。每次你读/听：＆＃39; X有Y＆＃39;，检查其含义是否实际上＆＃39; X由Y＆＃39;定义。或者＆＃39; X作为Y＆＃39;的分组标准。这里没有人可以告诉你你的应用程序的设计，我们只能告诉你一些原则和一些陷阱，但那就是它。没有公式，配方或最佳实践，只有理解域，然后建模使用代码。
您永远不会为您的特定问题获得通用DDD解决方案，因为在DDD中，每个解决方案都高度依赖于您的问题。而且你越早明白DDD是一种范式，而不是如何＆＃39;神奇的食谱，你会越好。否则，你会浪费多年时间做所有事情而不管DDD，无论你有多少个名为聚合根，存储库和实体的类。
答案 2 :(得分：0)
在我的项目中，我有模型（actor）的概念，因为我使用json格式的事件源，所以这个模型中的所有模型都被认为是组件。如果您想查看实际示例，请查看此项目的示例。 https://github.com/politrons/Scalaydrated