UseCase - A way to increase Elixir projects readability and maintenance based on "use cases" and "interactors"

Chat / Discussions
, , ,
1

A way to increase Elixir projects readability and maintenance based on use cases and interactors , the main goals are:

  • Single Responsability Principle
  • Composability
  • Readability
  • Screaming architecture
  • Enforce inputs and outputs of our project use cases
  • Better errors (know exactly where code fails)
  • Standardization
2 Likes
2

Hi @henriquefernandez this is definitely an interesting idea. I think a part of getting people to adopt something like this is providing examples that speak to more realistic or comprehensive examples. How would this look like with phoenix / ecto? How would this look like with several distinct tables?

2 Likes
3

Hi @benwilson512, thank you very much for the tip!

I made an improvement in the README and I intend to keep improving over time :grinning:

4

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

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.

Re: UseCase.pipe, the asymmetry in the argument list (struct followed by N atoms) feels weird. It also doesn’t seem particularly friendly to composition; is there a general way to take

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

and then pipe the result into a third use case C?

2 Likes
5

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 :slightly_smiling_face:

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!