Hi @al2o3cr, thank you for the tips.

IMO this needs work - the macro declares an input struct for the use case, but in a UseCase.pipe situation the input isn’t actually that shape (it’s the *.Output struct from the preceding step).

We can solve it pattern matching the interactor call function to receive its inputs or an another interactor output. In that way we are explicitly declaring that this interactor can be composed with another one in a specific way

Despite the ideas of forcing inputs and outputs, I tried to make the library as malleable as possible. We can use it in the way that suits us best.

AFAIK the style of indirect invocation used here is going to make it really hard for tools like Dialyzer to spot mismatches between inputs and outputs - they’ll only be detected at runtime. Consider enhancing things like pipe to enforce compatibility at compile-time.

I will study about it for new versions, thank you.

UseCase.pipe , the asymmetry in the argument list (struct followed by N atoms) feels weird. It also doesn’t seem particularly friendly to composition;

I did an update on it, now we can do that:

%A{name: "Henrique"} 
|> UseCase.pipe [A, B, C]
|> UseCase.pipe [D]

is there a general way to take
UseCase.pipe [%A{arg1: "foo"}, B]
and then pipe the result into a third use case C ?

I don’t know if I understood it very well, but we can do this:

UseCase.pipe [%A{arg1: "foo"}, B, C]

I really appreciate your comments! Thanks!