wouldn't it be better if the interactor returned new CreateUserResponseModel($user)
and then controller, command, etc. could decide on the type of response? Those layers could also get injected with a proper object handling the response (Presenter). It looks a bit weird that InputPort "knows" about OutputPort.
It can, but it wouldn't adhere to the specifications of this diagram:
With your proposal, the flow of control would return in the controller for it to make the decision on how to update the view, forcing you to change it when the use case changes.
In summary, you absolutely can, but it's no longer Clean Architecure, it's Laravel Actions.
I also don't believe it's weird to have the Interactor knowing the output port while implementing the input port since it should control both.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Hello,
wouldn't it be better if the interactor returned new CreateUserResponseModel($user)
and then controller, command, etc. could decide on the type of response? Those layers could also get injected with a proper object handling the response (Presenter). It looks a bit weird that InputPort "knows" about OutputPort.
It can, but it wouldn't adhere to the specifications of this diagram:
With your proposal, the flow of control would return in the controller for it to make the decision on how to update the view, forcing you to change it when the use case changes.
In summary, you absolutely can, but it's no longer Clean Architecure, it's Laravel Actions.
I also don't believe it's weird to have the Interactor knowing the output port while implementing the input port since it should control both.