1

In the context of Clean Architecture, is the following execution path right?

The controller sends a request model (input) to an interactor. The interactor executes a use case dependent on the request (input).

Is that right or am I mixing something here?

enter image description here

Improve this question
2
  • In addition the question. Is not the interactor, the use case itself? Is it a mediator? If yes, what's its main responsibility? Forwarding requests as a mere dispatcher?
    – Laiv
    Mar 12, 2019 at 17:56
  • 1
    You could implement this in different ways, of course, but the idea is not that there's The Interactor - a single master class that manages use cases. Interactors are use cases, and Request Model is just an interactor-specific input data structure (or just a set of parameters to a method) that forms part of its outward-facing interface, as a way of keeping it decoupled from code in the outer layer. It's just the data needed for the Interactor to do its work. Sure, you can encapsulate the input processing logic, but this wouldn't be part of the use cases layer.
    – Filip Milovanović
    Mar 12, 2019 at 18:06

1 Answer 1

Reset to default
2

An understandable misunderstanding

The interactor executes a usecase dependent on the message.

You actually got the words right, but I'm seeing from your graphic that this can be interpreted in 2 different ways. You interpreted it as

"The interactor chooses a usecase dependent on the message."

But it's rather

"The interactor executes a use case with the data from the message."

In your defense, the terminology can be confusing and sometimes different names are used to describe the same things.

An interactor represents a use case, not a list of use cases

In a way, an "Interactor" is a "use case". This is way easier to explain with an example though.

Imagine a web shop. In a business sense, you have the use case "add a product to the basket." The "recipe" for what happens in that use case is written down in a AddProductToBasketInteractor.

Now your user enters a number and presses a button in the outer "frameworks and drivers" layer. That layer passes the raw information on to your controller.

The controller puts the product ID and the number for the amount into a AddProductToBasketRequest - that's your "message". Then it calls AddProductToBasketInteractor.Execute(AddProductToBasketRequest).

Dependent on the message

Now, "executes a usecase dependent on the message" just means that what the interactor does has to do with the input it gets.

For example, how many products to add is dependent on the data in the message.

Maybe if the customer adds 10, they get 5% off.

Maybe the product ID does not exist, so it never actually changes the basket and returns an AddProductToBasketResult with an error flag.

No list of interactors

Your interactors "stand alone", they don't have to be put into a list of use cases.

An interactor coordinates "workers" in the "interface adapters" layer, so that a use case (the business term) happens.

Improve this answer
2
  • Thank you for your answer. So I would right something like "if input == "show data" usecase1.excute else usecase2.execute" in my controller?
    – davidh38
    Mar 12, 2019 at 18:37
  • 1
    @davidh38 Hmmm for a GUI, most often you wouldn't need that, because one button will only execute one usecase (e.g. a button "add to basket" will not call a RemoveProductFromBasketInteractor). However, I think I understand now that this is about a console application? In that case, yes that makes sense. You get raw string input from the outer layer, that's sent to your controller - then it's the controller's job to do the "grunt work" of deciding which use case to choose.
    – R. Schmitz
    Mar 13, 2019 at 10:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.