I agree with splitting by features over functionality, but there is a line with how far to take this. Phoenix draws a line (there are other lines to be drawn from there) between your business domain and the web domain which for me in my experience is “correct” (ymmv). Within the web domain, LiveView does the same in bundling up view/presentation and functionality by feature.

The business and web separation is useful in a several different ways. The main thing for me is that I want to treat my business domain as a kind of toolkit for building UIs around, possibly completely different clients (web, api, mobile, etc). Phoenix provides a little clue here in that the web namespace is MyAppWeb as opposed to MyApp.Web, but I think this elludes many people. `There is a thread here somewhere where someone puts it well by saying: “Think of the REPL as another one of your clients”. I find this to be a really nice balance of being flexible without getting into solving problems I don’t yet have. Now even if you know that you’re only ever going to have a web interface, it still isn’t always going to map 1-to-1 with your business logic which you even alluded to. There might be another part of the site where you want to reuse some some domain logic so it wouldn’t make sense to mix them. Finally (well, there are probably more reasons but I’ll stop here), having the domain logic categorizes all the “backend” functionality together making it very easy to browse and find stuff.

As for tests, I personally would never co-locate them. I’m a huge proponent of testing but I don’t take the “the tests are part of our app” stance; I think of them as yet another client. They also don’t always map 1-to-1, especially end-to-ends. Dave Thomas did give a good talk on the directory structure being wonky. It’s something I had thought about myself before but I’ve never found it to be a hindrance. It’s one of those things that if it changed I’d be like, “Oh ya cool, this is a little better” but I really don’t think it’s as big an issue as some make it out to be. And I certainly wouldn’t call any of the top level directories insignificant.

I have plenty more to say on this topic (especially around messy context files… they don’t need to be!) but that’s probably enough for now and my dog needs to go out. I will say, though, that Phoenix is very flexible and you have to do what makes sense to you! There are advantages to at least somewhat adhering to what’s suggested for us, especially if you’re working for a company and want to onboard people quickly, but it’s by no means necessary. I’m more just trying to shed some light on why things are the way they are and why I actually quite like it the way it is.

Elixir and Phoenix conventions are accumulation of the last decade.

It goes a little farther back than that. From a newbie’s standpoint, I would say that the two biggest influences on Phoenix conventions that you should care about are Ruby on Rails and Domain Driven Design.

…except that you don’t need to care at Rails if you don’t already know it. I’m a former Rails developer and have a massive soft spot for it (I still think it’s a very viable option if you’re deep into OO), but Phoenix has done a lot of really good work since its inception to make itself less like Rails. The influence is still there and it’s not a bad thing because Rails is not all bad.

Domain Driven Design (DDD), on the other hand, is very pertinent to Phoenix. It’s a very large topic but Phoenix’s Contexts come directly from DDD’s Bounded Contexts. The DDD book itself is massive so I recommend reading the very digestible DDD Distilled as a gentle introduction. I’ve honestly never read the full DDD book cover-to-cover—that book literally has a bunch of paragraphs in bold and says, “If you feel confident and don’t want to read this whole book, just read the bold paragraphs”.

Of course, like any concept in programming, there is an army of people who are anti-DDD. Are they right? Who knows, but at least peruse the previously linked Martin Fowler short article for prior DDD art.

I’m also very sorry if I’m telling you stuff you already know (programsplaining? lol)

The priv directory is kind of special, as it is included in the release. For that reason, you usually only put stuff there which has to be there for the app to function. So I would not recommend putting assets and rel folders in there.

About the rest, I have no strong opinions. If you stray from the defaults it may be a little more work to onboard people who are used to the Phoenix conventions. But if it works well for you, then there should be nothing stopping you. Phoenix has conventions, but it is also very flexible.