Clean architecture: use case mixing

user_14749936 0
Viewed 579

I'm trying to understand how clean architecture works, last project i had a user, he can add a payment card and buy a subscription (example use case), but when it's new user, add and buy integrated as one step

Use case sample

According to what has been read, it should have two "Interactors", one "AddPayment" and "Purchase", , but... how can I mix: The user can do both separately, but when he is new, in registration process he adds the payment method and makes the charge in one step,

I think I should have an "Add and pay" use case, but it would have repeated code and a broken paradigm, I see these options:

  1. Make a third use case with repeated code
  2. Merge from controller
  3. Make a use case that calls the other two

How have you solved it?

clean-architecture
1 Answers

I usually make a base use case that calls the other two. For this base use case I define a new request model that contains the request models of the others . The same applies for the response model. But sometime the request or response models have something in common and I create more condensed models.

I think that a base use case fits best to the include relationship of the use case uml model.

            +-----------+
            | AddAndPay |  
            +-----------+
             |         |
             V         V
         +-----+    +-----+
         | Add |    | Pay | 
         +-----+    +-----+

The AddAndPay use case also handles failures of one of the use cases. E.g. if pay fails you might not want to add a payment card. Maybe you must invoke a RemovePaymentCard use case then or your transaction boundary is the AddAndPay use case.

user_9741860
Related