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