在我们的系统中，我们有一个数据库，其中许多表都有很多列，在某些情况下超过 300 列。让我们举个例子——一辆车。我们有一个包含 300 列的汽车表。除了汽车的 id 之外，其余列包含与汽车效果相关的数据。右侧座椅的尺寸。
问题是我们如何在不加载所有列的情况下将此表映射到 DDD 聚合中？
DDD 说存储库会加载整个聚合，但在大多数情况下，客户只想查看聚合的一小部分。car aggregate 也会有很多计算各种事物的方法，有些情况下需要从其他表中加载数据。
我们如何以 DDD 的方式实现这一点？域服务？
我们是在找错树了吗？我们应该改用 CQRS 吗？
请无视事实；数据库是一团糟。
看来您的问题是您将聚合和用户希望看到的视图 1:1 映射。仅仅因为我们谈论聚合，它不是 1:1 的视图。（您自己说的“但在大多数情况下，客户只想看到聚合的一小部分”）。
使用 CQRS（或“仅”CQS）的一个好处是您可以专注于域，这意味着您可以从用户/客户的角度为您的命令和视图（eq 查询）建模，而不管您当前的数据库设计。
看看Vaughn Vernon 的有效聚合设计，它可能会有所帮助。
CQRS 和 DDD 并不相互排斥。该领域应专注于行动/计算/“实际”工作。您可能希望使用读取/查询层来获取用户希望查看的数据子集。
尽量不要查询您的域。如果您发现自己提出了您现在提出的问题，这通常意味着您正在或正在考虑查询该域。那只会导致痛苦。
所以 DDD 和 CQRS 可以很好地协同工作。CQRS 也有不同级别，因此您需要正确平衡 :)
在简单的 oop 中，如果您发现某些行为只需要字段的子集，您可以将它们提取到另一个类并将实现委托给它。
在您的汽车案例中，您可以进行相同的重构。然后你可以使用延迟加载：首先加载汽车，并在需要时加载汽车的其他本地实体。我认为这更像是一个基础设施问题，而不是领域驱动设计。
当然，如果您发现持久性基础架构阻碍了您进行建模。您可以使用单独的持久性对象。但这在开始时需要更多的资源。
另一方面，如果你有一个遗留数据库，我认为采用 CQRS 会更难。这可能会给你的团队带来太多的负担。