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.

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.

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.