Scalable Elixir/Phoenix Project Structure

Hi all,

I had this question for a while doing some hobby projects in Elixir.
When comes to enterprise-level applications, code organization takes a crucial place.

In a large project I would love to keep related files together(group by domain).
like for example in NestJS im doing for user module

- models
--- user.model.ts
- jobs
--- user-cleanup.job.ts
- user.controller.ts
- user.resolver.ts
- user.service.ts
- user.service.test.ts
- user.module.ts

Now the best part is in UserModule I can import all the related services/controllers/resolvers and let DI initialize them for me without wiring logic in multiple files. (This may be not possible with Elixir as DI heavily use OOP concepts)

I really enjoy this because previously I used MVC which did not scale when the project was getting complicated. had to look up multiple files in different locations to do some tasks. But now instead I know exactly where the files should be and I don’t need to load them in multiple places.

Does anyone follows a similar pattern or are there any alternative scalable approaches we can use in the Elixir world?


Elixir is quite flexible on the architecture, and there is no relation between the location on the File System and the name of the modules. You can use multiple…

  • standard context structure
  • poncho architecture, promoted by @pragdave in his course.
  • hexagonal architecture
  • onion…

You might be interested by


Thank you, I will consider the options you mentioned

1 Like

There was a recent forum topic on exactly this point. However I’m having trouble finding it from search. Does anyone have a link to it? The poster ended up with a per-feature file structure if I recall correctly.


I saw it too, but don’t remember where :slight_smile:

1 Like

I remember this discussion, not sure if it is the same one you are referring to.


Thanks but I was thinking of a different topic that was specific about the folder structure of a Phoenix application.


Maybe Discussion about domain-orientated folder structures in Phoenix? OP actually already asked there though. There are a few backlinks there too, attached to the first post.


At risk of going off on a tangent, where does the idea that architecture is related to how source code is stored on the file system come from? This is not the first time I’ve heard it. Architecture is about runtime interactions and boundaries between components, regardless of which source file defined the components.

Yes, project layout conventions are very useful, especially on large teams, and they may somewhat reflect architectural patterns used in the project. It’s a fine topic to discuss. But I see it as clearly distinct from architecture.


I’ve edited the title :023:

Don’t know about a recent topic… but I found this post here quite useful: Concrete examples of when to use live_patch, live_redirect, push_redirect, push_patch? - #12 by benwilson512


Me too. Not sure if it disappeared. insert conspiracy


Great. That is a benefit for future searches on the forum. However, if someone knows some university or bootcamp or language community (or other) that uses “architecture” in this way, I’m still quite curious of the root source of it.

1 Like

I guess they’re thinking along the lines of architectural patterns?

Can you remember who posted it? If you go to their profile you should be able to see a list of all their threads :smiley:

I don’t recall it myself…

Found the post on folder structure for Phoenix applications! I hope it’s helpful for you!


This is also a related discussion, I also have commented there the same thing Discussion about domain-orientated folder structures in Phoenix - #2 by chrismccord . It appears the discussion ended without a proper solution to address the problem :frowning:

I saw it maybe at most 1 week ago. I think it was a new post (but cant swear it wasnt an old post with a new comment).

Aha yes this is the one I thought about.

1 Like