我在正确设计我正在处理的域时遇到了一些问题。
我的简单用例如下：
用户(约5000名用户(可以访问广告列表(约500万(
他可以选择将其中一些作为收藏夹添加/删除
他可以决定展示/隐藏其中的一些。
我有一个命令，它会改变聚合状态，比如说，将Favorite设置为TRUE。
就DDD而言，我应该如何设计骨料
如何设计用户和他最喜欢的广告选择之间的关系
考虑到广告数量巨大，我无法在用户聚合根目录中复制每个广告
我可以设计一个包含用户的广告聚合根吗；集合"；。
最后，如何处理/执行自述文件部分？
提前感谢
干杯
有两个概念可以帮助您理解如何对此进行建模：
1.聚合是事务边界
聚合是被视为单个单元的关联对象的集群。聚合的所有部分都被加载并持久化在一起。
如果您有一个包含1000个实体的聚合，那么您必须将所有实体加载到内存中。因此，在任何可能的情况下，你都应该最好有小的聚集体。
2.聚合是不同的概念
聚合表示域中的一个不同概念。与多个聚合相关联的行为(在您的情况下，如Favoriting(通常是一个具有自己的一组属性、域对象和行为的聚合。
根据您的示例，User是一个清晰的集合。
Ad在域中有一个与之相关的独特概念，因此它也是一个聚合。可能存在将嵌入广告内的其他实体，如valid_until、description、is_active等。
偏好广告的概念链接了User和Ad聚合。你的问题似乎集中在这种联系应该保留在哪里。它应该在User聚合(Ads的列表(中，还是Ad中应该嵌入User对象的集合？
虽然两者都是可能的，但IMHO，我认为FavoriteAd是另一个聚合，它包含对User聚合和Ad聚合的引用。这样，就不会给User或Ad的概念带来偏袒行为的负担。
这些聚合也不需要每次将这些附加数据加载到内存中时都加载这些附加数据。例如，如果要加载Ad对象以编辑其内容，则默认情况下不希望将收藏夹集合加载到内存中。
就读取模型而言，这些聚合结构并不重要。聚合只处理域的写入侧。您可以在read端以多种形式随意重新连接数据。您可以让一个订阅者只监听Favorited事件(在处理Favorite命令后引发(，并构建一个包含User和Ad聚合数据的复合数据结构。
我真的很喜欢Subhash Bhushan给出的答案，我想添加另一种方法供您考虑。
如果你仔细观察你的问题，你会发现你已经假设聚合可以"看到"用户在与UI交互时所做的一切。不需要这样。
根据域名的要求，你不需要持有任何广告的列表来收藏它们。我的意思是：
对于这个例子，"最喜欢的"广告命令位于哪里并不重要。它可以在用户聚合上，也可以是用于处理优惠概念的特定聚合。该命令只需要保存用户的id和他们喜欢的广告。
如果用户或广告被删除，您可能需要处理会发生什么，但这只是事件流程管理器监听适当事件并发出补偿命令的情况。
这样你就不需要加载500万个广告。这是阅读模型和用户界面的工作，而不是域。
只是一个想法。