Use Case Interactor应该在Clean Architecture中有多大或多小？

Question

我正在尝试使用Clean Architecture和DDD来确定如何最好地定义用例。假设我有一个应用程序来处理交货的拣货，包装和运输。这是流程：

1. 用户输入传递以使用送货信息填充屏幕
2. 用户选择订单项并点击按钮进行选择
3. 用户输入包裹信息（例如，重量和暗淡），然后单击按钮以打包。
4. 用户点击“发送”按钮调用外部系统以获取发货标签

以下是我正在考虑定义我的用例交互者的选项：

1. 创建4个Interactor类，上面列出的每个步骤一个
2. 使用4种方法创建1个Interactor类来处理上面列出的步骤

3. 创建3个Interactor类

   一个。 Interactor 1将处理Enter Delivery和Pick

   湾Interactor 2将处理包装

   ℃。 Interactor 3将处理Shipping

提前谢谢！

Answer 1

这取决于业务规则：系统的有效状态是什么？在这种情况下，系统是DeliveryAggregate。

• 如果允许系统在给定时刻处于4种状态中的任何一种状态，则可以使用4种Interactors或单Interactor种4种方法。

• 如果系统只能处于3种状态（即Picked，Packed或Shipped），则可以再次使用3种Interactors，或仅使用3种方法。 p>

您可以在此处应用Single responsibility principle并选择单独的Interactors。

因此，总之，Interactos设计强烈推动Aggregates设计，因为Aggregates是一致性边界。

Answer 2

对我而言，一个交互器体现了一个用例，一个用例由一个交互器体现。

因此，对于一个由几个步骤构成的用例，我会想知道，对于每一步：该步骤是否是一个有效的用例？

将seeing shipping information视为用例是有意义的，但将select line item and mark it as picked视为用例是否有意义？

如果答案是肯定的，那么制作一个关联的Interactor。否则，它可能不会特定于一个业务规则而不会在您的应用程序（业务范围）中重复使用，因此为此创建一个Interactor是不必要的。浏览用例时，您不希望在屏幕上看到它！

请注意，此观点的结果与Constantin的答案结果相同。