How does the control flow relate to the "Clean Architecture" control flow? about buckpal HOT 3 CLOSED

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 :).

from buckpal.

👍 thanks!

from buckpal.

this is from DDD distilled by Vaughn Vernon

from buckpal.