Discussion about domain-orientated folder structures in Phoenix

I have to agree: as a newcomer to Phoenix, the default folder structure is quite overwhelming coming from something like Django where all apps (contexts) are cleanly separated with distinctive folders.

It reduces cognitive load. I might actually hack together a similar folder structure with my Phoenix app…

1 Like

As an experienced Django developer myself, the Django app structure encourages tightly coupling business logic with the web/http layer. It’s part of Django’s strength but also a weakness when you want more flexibility (which is inevitable in any mature project).

I prefer Phoenix folder structure of explicitly separating out the domain layer (or contexts) from the web layer. I was also overwhelmed at first but once you create a mental model of how Phoenix structures code it becomes second-nature.

2 Likes

Perhaps unintentionally just by their nature, Phoenix has basically followed this evolution of combining the view and controller with LiveView and with co-located templates it seems to match a lot of previous discussion in this thread. What’s that saying, everything else is just a buggy incomplete re-implementation of lisp small talk? :thinking:

I wonder if co-location will bleed back through to static controller/views eventually to unify phoenixes mental model. I know manually flipping this isn’t too difficult though.

It would be interesting to hear from previous posters in this thread on whether they did restructure future projects and how they feel about it now, considering the discussion was 2-3 years ago.

1 Like

I think the distinction between “whether we should separate domain layer/contexts from web layer or not” (call that A) and “whether we should separate the web layer by domains or by layer” (call that B) has been made sort of implicitly. Some comments here talk about A, many talk about B.

I think that A is well accepted, which is good because I feel it’s correct :+1:

B is the one that’s more interesting to me… Personally, I’d agree that I work vertically within the web concern. In other words, I often make changes within one domain, but across multiple ‘layers’ of templates and controllers. This is slightly contrary to the Phx default.

3 Likes

Hi all,

I’m also concerned about this. Was thinking to port an existing Node application into Elixir/Phoenix. In that, I’ve used a similar pattern to the Phoenix default structure. But recently I started to use NestJS which provide out of the box domain-related directory structure for your code.
This reduces the time switching and finding related files.
It’s even easier for a newcomer to understand the project.

NestJS modules

user
- 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

I would really love to see some light on this because in a large scale project this is actually a problem we need to address sooner or later.

Some official guidance would be really awesome, as people will actually face this problem

1 Like