stored-procedures - 存储过程中的海量数据操作到 DDD

Question

让我们举一个 的例子产品 分类。 所有产品都需要归类为蔬菜与否。 业务逻辑是，如果产品来自 A、B 和 C 公司，则该产品可以归类为蔬菜。如果产品不是来自这些公司，则它们不是蔬菜。有数百万种产品。这可以在存储过程中用几行代码完成。如果同步完成，该操作可能只需要几秒钟。

据我了解，DDD 与将逻辑放在存储过程中的想法背道而驰。该逻辑可以作为产品的行为，可以根据谁是来源进行自我分类。为此，需要将所有百万产品读入内存，进行处理，然后将其保存回数据库。

这里的问题是此操作需要大量内存。如果操作是在 50,000 个卡盘中完成的，那么存储库必须首先弄清楚产品需要如何分类，并且应该告诉域长时间运行的操作必须分块进行。当然，这种方法将花费更多的时间，并且对于必须等待比存储过程所需的时间更长的进程的用户来说，会带来糟糕的用户体验。

对于长时间运行的进程，DDD 的合理方法是什么？延迟是否预期，因此应用程序必须通知用户分类需要时间，并在完成时通知用户？并且不应该使用存储过程，而是具有域的逻辑部分。

更新

只是为了增加一些清晰度，这种分类过程经常进行。应用程序必须支持分类过程，而不是 ETL 或不能等待更长时间。这就是为什么我试图找到使用存储过程与 DDD 之间的权衡。

另请注意，它不是查询，而是命令。该命令可以称为 ClassifyAllProductsCommand()。运行此命令时，之前没有分类。分类后，系统的其他用户应该会看到新的分类。例如，产品 A 被归类为 Unavailable，归类后它可以是蔬菜或肉类。

Answer 1

分类是一件很有趣的事情。这是一个单独的事情。分类永远不应该作为结构来实现……但那是另一回事了:)

您的分类甚至可能被视为有界上下文，就像报告可能是有界上下文一样。因此，您可能希望单独处理分类。您的分类不是聚合根。它起到辅助作用。如果它对您的域建模的一致性没有影响，它甚至可能不一定是您的 Product 的一部分。总计的。它可以添加，甚至可以独立更改(不是批量更改)，但如果它用于确定您的聚合的有效性，那么您的分类子系统将不得不考虑到这一点。

请记住，这不是 DDD 与存储过程的问题。您正在对数据存储执行查询。无论是通过存储过程还是动态完成，都不应该影响您的决定。例如，没有什么可以阻止 ProductRepository从调用存储过程。

您可以让您的分类子系统仍然执行您的 SP 或直接使用 DML。但是，这不一定会成为您域的一部分。如果它经常发生并且作为批量操作发生，您肯定不想单独对每个产品进行分类。如果您当前的设计要求这些是批量操作，那么请保持原样，不要强制它们进入会被禁止的 DDD 结构。

这是一种设计选择，有时对单个项目进行更改没有意义。一次处理单个聚合当然应该是您的目标，但诸如报告或分类之类的东西是另一种并不总是完全适合领域驱动设计思维的动物。