My context related business logic lives in lib/my_app/domain/domain.ex.
I read this blog post a while back and to the best of my understanding it suggests to keep schemas clean and free of anything but the schema definitions, and favor putting any changeset definitions in the context (read the ‘Schemas are not models’ section of the blogpost’).
What is the most recent take on this, where should my changeset definitions for entity and actor go?
Don’t get too hung up on how other people organize their projects. Find a way that looks intuitive to you and your team. The most important metric should be this one:
“How do I organize the project so that if I get a 3 months of vacation I’ll be able to decipher what I did immediately after coming back?”
FWIW, phx.gen.schema includes import Ecto.Changeset as part of every generated schema file. I’d consider that a strong endorsement from the framework for putting changeset functions in schemas
Thanks!
I’ve eyed through the docs linked by @Eiji, and based on that and the way the phx.gen.schema behaves I have decided to put my changeset def in the schema files with @doc false, and use specialized functions in the context as a gateway to access them.