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

时间:2017-12-22 00:00:14

标签: domain-driven-design clean-architecture

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

  1. 用户输入传递以使用送货信息填充屏幕
  2. 用户选择订单项并点击按钮进行选择
  3. 用户输入包裹信息(例如,重量和暗淡),然后单击按钮以打包。
  4. 用户点击“发送”按钮调用外部系统以获取发货标签
  5. 以下是我正在考虑定义我的用例交互者的选项:

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

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

      湾Interactor 2将处理包装

      ℃。 Interactor 3将处理Shipping

    4. 提前谢谢!

2 个答案:

答案 0 :(得分:2)

这取决于业务规则:系统的有效状态是什么?在这种情况下,系统是DeliveryAggregate

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

  • 如果系统只能处于3种状态(即PickedPackedShipped),则可以再次使用3种Interactors,或仅使用3种方法。 p>

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

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

答案 1 :(得分:1)

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

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

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

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

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