I’ve observed this as well and I’ve diverged more and more from Phoenix scaffold over time. I think of it kind of like a pattern for a suit. It might work well unaltered for a certain range of people/venues, but as the tailor it’s my job to know who is going to wear it where, and with what shoes, and cut and shape accordingly.

To be a bit more specific, following Saša Jurić I first started managing changesets right in the context, ditching the schema changeset functions. But this does make context bloat even worse so I have started moving create/update functions back to schemas, reserving contexts for true “glue code” (e.g. ‘new registration’ endpoint that creates several rows across tables, and sends an email, etc), something I doubt he would endorse. But on this very forum Saša has given advice contradicting guidance in those articles, so the main thing I follow him on is not being too attached to the purity of abstract rules. More than anything, I hate premature optimization with a passion so I try to always be guided by the domain rather than framework boilerplate, even a framework as well thought out and designed as phoenix.

One caveat: consistency does have a lot of intrinsic value that has to be balanced against this kind of customization/experimentation in a domain, especially when larger teams are coordinating on a project. Sometimes its worth erring on the side of “prematurity” when abstracting domain logic if it keeps everyone on the same page. But personally this is why I avoid larger teams