I kind of am in the generic camp as well, but with a twist. We run multiple projects as an agency and it makes somewhat switching between these projects easier. What I think about “generic” names are not the same @gshaw does, however. My usual set up is that we start with umbrella project containing:
- apps/db - ecto schemas go there, no or very little business logic
- apps/core - the “services” layer if you want, workflows that handle business logic
- apps/ui - the Phoenix user interface. This does not further have ui_web as it’s not necessary, everything in UI is “web” so no need for extra namespacing
- [maybe] apps/admin - another Phoenix interface, or maybe just namespace where things like exq admin panel, LiveDashboard etc. are mounted and exposed under different port / host than UI
- [maybe] apps/api - Phoenix/Absinthe endpoint if UI needs API or app has separate API it exposes
And these apps have “generic” lib folders such as “apps/db/lib/db” and “apps/core/lib/core” etc. There is no space for app name, i.e.
demo anywhere, usually.
I don’t think merging two projects happens often enough to justify
PrefixingEverythingWithYourProjectName. and having a ‘top-level namespace’ for all modules is just adding to the typing and reduces developer experience. When you have to rename things, the
sed and/or IDE that can help with refactoring comes in handy.
With my scheme, whenever I am stepping in the project I can assume there will be
UI.Endpoint, and something like
Core.Registration or similar. Makes life just a bit easier to standardize.