Struct and complex logic

Complex structs like %DateTime{} are a good example where the external users are discouraged from pattern matching directly on the struct fields, and should use the functions provided by the module to transform the value.

For Ecto shemas I like to put the functions that produce changesets in the schema module, then the higher level business logic that manages the transaction scope in context module function, or even a dedicated module for handling each command.

So you recommend using functions in struct for data transformation not for logic using it , like high level business logic dealing with other context modules ?

Yes that’s the approach I follow.
Declare data structures and the functions to transform them in the same module.
Then separately the business use cases in other modules.

Domain Modelling Made Functional is a good reference on organising code with domain models and workflows.

Thanks, I also was thinking about this approach.
I will look at it to see if it suits well.

Do you think struct functions must only be pure ( without side effect: genserver, ets, database call) ? And reserve those to more statefull modules or business workflow modules ?

Do you think struct functions must only be pure

For application code, that’s probably a good rule to follow, it aligns with the ‘functional core, imperative shell’ architecture style.

However for library code, there are examples where it doesn’t apply:

Plug.Conn is mostly pure functions, but it also contains the necessary functions like read_body and send_resp which aren’t pure.

Ecto.Changeset has unsafe_validate_unique that makes a DB call while most other validations are pure.

Mostly yes but don’t get religious about it. It’s okay for your business logic functions to depend on Ecto and Plug which have stateful (impure) parts. Utilise some tooling (like the boundaries library by @sasajuric) to check for dependencies you don’t want to allow but outside of that, don’t sweat too much about it.