I would also recommend reading a multi part series as well that Sasa wrote: Towards Maintainable Elixir: The Core and the Interface | by Saša Jurić | Very Big Things | Medium

That’s one part of the 4 I think, of which every single one has incredible value to be pulled from. Like anything, don’t be too dogmatic about it, it’s very likely you won’t nail it the first couple of times, but as long as you have these concepts in the back of your head, certain patterns tend to emerge.

I like. what Sasa does in his talks, eg Clarity | Saša Jurić | ElixirConf EU 2021 - YouTube

One trick is to generate a new Phoenix app in some scratch directory, use Phoenix schema etc. generators there, read the generated code, and then implement something similar by hand in your real app, putting everything where you want it.

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