根据您的术语，我假设您正在根据 Eric Evans 的书执行 DDD。听起来您已经在最初的建模过程中发现了一个问题，并且您做对了。
你提到你认为供应商是Value Object......我认为不是。AValue Object是主要由其属性确定的东西。例如，日期“2009 年 9 月 30 日”是一个值对象。为什么？因为具有不同月/日/年组合的所有日期实例都是不同的日期。具有相同月/日/年组合的所有日期实例都被视为相同。我们永远不会争论将我的“2009 年 9 月 30 日”换成你的，因为它们是相同的 :-)
Entity另一方面，主要由其“ID”标识。例如，银行账户有 ID - 它们都有帐号。如果一家银行有两个账户，每个账户有 500 美元，如果他们的帐号不同，那么它们也不同。它们的属性（在这个例子中，它们的平衡）不能识别它们或暗示相等。我敢打赌，即使银行账户的余额相同，我们也会争论交换银行账户:-)
因此，在您的示例中，我会考虑一个供应商Entity，因为我假设每个供应商主要由其 ID 而不是其属性来标识。我自己的公司与世界上另外两家公司同名——但我们并非都可以互换。
我认为您的建议是，如果您需要视图来对对象进行 CRUD，那么Entity根据经验，这可能是正确的，但您应该更多地关注使一个对象与其他对象不同的原因：属性或 ID。
现在，就目前而言Aggregate Root，您希望专注于对象的生命周期和访问控制。考虑到我有一个博客，其中有很多帖子，每个帖子都有很多评论——这些Aggregate Root（s）在哪里？让我们从评论开始。在没有帖子的情况下发表评论有意义吗？你会创建一个评论，然后去找一个帖子并将其附加到它上面吗？如果你删除一个帖子，你会保留它的评论吗？我建议一个帖子是一个Aggregate Root带有“叶子”的帖子 - 评论。现在考虑博客本身——它与帖子的关系类似于帖子和评论之间的关系。在我看来，它也是一个Aggregate Root带有“叶子”的帖子。
所以在你的例子中，公司和供应商之间是否存在牢固的关系，如果你删除一家公司（我知道......你可能只有一个公司实例），你也会删除它的供应商？如果你删除“星巴克”（美国的一家咖啡公司），它所有的咖啡豆供应商都将不复存在吗？这一切都取决于您的域和应用程序，但我建议您很可能都不Entities是Aggregate Roots，或者考虑它们的更好方法是它们是聚合根，每个都没有“叶子”（没有聚合）。换句话说，公司不控制对供应商的访问或控制供应商的生命周期。它只是与供应商建立一对多的关系（或者可能是多对多）。
这将我们带到Repositories. ARepository用于存储和检索Aggregate Roots。你有两个（从技术上讲，它们没有聚合任何东西，但比说“存储库存储聚合根或不是聚合中的叶子的实体”更容易），因此你需要两个Repositories. 一份给公司，一份给供应商。
我希望这有帮助。也许埃里克·埃文斯潜伏在这里，会告诉我我在哪里偏离了他的范式。