This is just a case of internal team culture and practices – and prominently, of code reviews and approval processes. If my endpoint apps (Phoenix controllers, GraphQL resolvers etc.) only use my domain app – via in_umbrella: true for example – and do not use the app with the direct storage helpers in it (Ecto et. al.), then that’s a very clear sign for the programmers not to take shortcuts.
Ultimately, I do not think there is a way to fully enforce clean boundaries. It’s up to us to facilitate practices that make our work more predictable and productive. The pursuit of academic purity is something I wish we had more time for but as it is, the modern IT business is heavily against it.
(EDIT: This reminds me that a pre-commit hook that makes sure your phoenix_controllers app does not call anything from your storage app – via grep’ing mix xref – is something I wanted to do for a long time.)
I mean, if you just want to keep your modules in separate directories to make it easier to enforce coding standards, you can. There is no rule they all have to be in lib. Just add them to your compilation path. What I think is more important is how those modules collaborate with each other, and making them separate “apps” imposes no restrictions on that. It doesn’t draw a bright-line around your modules, but it does introduce certain complications of sharing non-code resources and it seems like there is a new question on the forums every week about how to work-around that.
All true. It is mostly related to human perception IMO; if things are separated in “apps”, “bundles”, “module collections”, “class libraries” etc. then us the people think that bundle to be a semantically isolated unit – which is true often enough but many times it isn’t because it’s simply a device to make the life of the code organizer a bit easier.
To reiterate part of my above comments: for most devs I ever met – even the juniors and the interns – it instinctively makes sense not to breach boundaries where you have a small mechanical hurdle before doing so. Thus I try hard in my work to exploit such brain bugs (or hacks or if you will) in order to make people play nicely with my code. Saves time, saves unnecesary discussions, and works most of the time. And when it doesn’t, I can explain why I do things the way I do – in 2 minutes.
In my experience it definitely does draw the said bright line but we come from different backgrounds and societes so that’s surely a factor in it as well.
As for sharing non-code resources, that’s a problem most programming languages still haven’t solved reliably. I’d go radical and make an entirely new OS that has an OS-wide key/value store that can be a file / string / number / whatever and be it read-only 99% of the time (and have additional security attached to it, like who can even view it). I see no reason to maintain configuration or static assets the way we do it right now – deployment with such a new system would be brain-dead easy… But anyway, we can dream.
In Elixir’s case the priv/ directory IMO complicates more things than it solves. But I have no better idea so I am not bad-mouthing it. Often, it’s a good enough mechanism.
