How does the control flow relate to the "Clean Architecture" control flow?

[jaylensoeur]

Hi @thombergs, I'm trying to understand your version of flow of control. It seems that you're advocating for a controller->usecase->controller->web sequence of control flow. I'm struggling to understand your concept of the output port - it seems to refer to it as being a persistence boundary interface, that is not what my understanding of clean architecture by Uncle Bob is saying. When Uncle Bob talks about output port he is referring to a Presenter concept, not persistence.

Also, from the flow of control diagram we see that the control is passed from the controller -> usecase -> presenter where the controller is the input port and the presenter is the output.

https://softwareengineering.stackexchange.com/questions/357052/clean-architecture-use-case-containing-the-presenter-or-returning-data

am I missing something? Can you please clarify this from me.

[thombergs]

Hi @jaylensoeur

you're right, the input and output ports I discuss in my book and use in the Buckpal application don't match with Uncle Bob's definition at first sight.

The control flow above is only applicable to a UI-based application (fat client) where the use case implementation needs to change the state of the UI. So, the use case implementation (what he calls an "Interactor") calls an interface (output port). The implementation of that output port (the "presenter") reacts to this call and changes the state of the UI.

The above doesn't work for server-side web applications, because they don't have a UI.

Instead, I took the idea of the input and output ports from Hexagonal Architecture. The control flow is the following:

• Controller (i.e. SendMoneyController)
• Use case input port (i.e. SendMoneyUseCase)
• Use case implementation (i.e. SendMoneyService)
• Use case output port (i.e. LoadAccountPort)
• Output port implementation (i.e. AccountPersistenceAdapter)

If you look closer, it's pretty much the same as in Uncle Bob's picture above, though. The only real difference is that the output port doesn't change the state of the UI, but the state of the database.

If you have an interactive UI, nothing prevents you from implementing an output port that changes the state of the UI, too (from a web backend, you'd have to use something like Websockets to do that, though).

So the two concepts are compatible, after all :).

Does that answer your question? It was fun to answer, made me understand it a bit better, too :).

[jaylensoeur]

:+1: thanks!

[jaylensoeur]

this is from DDD distilled by Vaughn Vernon