domain-driven-design - 干净架构中的用例交互器应该有多大或多小？

Question

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

1. 用户输入交货以在屏幕上填充运输信息
2. 用户选择订单项并单击按钮选择
3. 用户输入包装信息（例如重量和尺寸）并单击按钮进行包装。
4. 用户点击发货按钮调用外部系统获取发货标签

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

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

3. 创建 3 个交互器类

   一个。交互者 1 将处理 Enter Delivery 和 Pick

   湾。交互器 2 将处理包装

   C。交互器 3 将处理运输

先感谢您！

Answer 1

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

• 如果系统在给定时刻被允许处于 4 种状态中的任何一种，那么您可以拥有 4Interactors种或单个Interactor4 种方法。

• 如果系统只能处于 3 种状态（即Picked或Packed）Shipped，那么同样，3 个交互器或只有 1 个但具有 3 种方法。

在这里您可以申请Single responsibility principle并选择单独Interactors的 .

因此，总而言之，Interactos设计是由设计强烈驱动的，Aggregates因为Aggregates它们是一致性边界。

Answer 2

对我来说，一个交互器体现了一个用例，一个用例由一个交互器来体现。

因此，对于由多个步骤组成的用例，我会想，对于每个步骤：该步骤本身是否是一个有效的用例？

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

如果答案是肯定的，则创建一个关联的交互器。否则，它可能不会特定于某个业务规则并且不会在您的应用程序（业务范围）中重用，因此没有必要为此创建一个交互器。当您浏览用例时，您不会希望看到它在屏幕上弹出！

请注意，从这个角度来看的结果与康斯坦丁答案的结果相结合。