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