Interactor for "multi-step" use case

[Facundo Javier Gelatti]

I am having problems when trying to implement the interactors using the command pattern for "multi-step" use cases, such as "Process Sale", in which you are incrementally performing the use case instead of sending all the data at once (first initialize the sale with the current date and logged in employee, then add the items one by one showing the details of each one and updating the total, and finally register the sale with its payment, validating the data incrementally).

Additionally, most of the time the order in which the operations are executed in this kind of use case should also be validated (for example, cannot enter an item if the sale was already paid).

If we want to implement this kind of use case, will only one interactor be needed, or one per operation? (for example, one to start the sale, another to enter an item, and so on) Where do we keep the state of the transaction? And should we separate that state from the operations that modify it?

[Sebastian Gozin]

I do this client side and just send the full order once fully compiled and apply validation and any other logic on that.
If you want to save your draft server-side I would treat it as a draft and still when placing the order copy the information from the draft into the actual place order usecase and delete the draft.

[Facundo Javier Gelatti]

I was thinking on a desktop app, but still, if that is done in the client side the same questions apply. Where (being in the client side) will all the business rules that must be checked at each step be validated? (the order of the operations, the retrieval of each item's detail, the calculation of the totals, the payment management, and so on) Where do we keep the state of the use case? (On which object or objects?)

[Imre Kószó]

I believe you should persist the user's progress through the process as part of your entities. Assembling the order seems like a longer process and in my opinion the draft orders are something the business needs to track. What if the user is putting together a giant order and their computer (or your server) crashes halfway in? You would want to enable them to continue. Your usecases could be CreateDraftOrder, AddItems, FinalizeOrder etc.

[Sebastian Gozin]

There is such a thing as local storage though. So the possibility of system crashes isn't necessarily an issue.