Discussion on: I am the author of Elm in Action. Ask Me Anything!

Sure! I should emphasize that we don't put a big priority on "getting this right." More than anything we try to be consistent (but don't always succeed), and the compiler makes it pretty easy to rename things if we change our minds, so we don't sweat it. (The biggest drawback to renaming is plain old vanilla merge conflicts.) So I wouldn't take any of this as advice so much as a data point if you're curious. :)

We have a series of pages, e.g. "Teacher Dashboard", "Grading", "Splash Page". Each of these has its own main; back when I joined the company we were a non-SPA Rails app, and we have not transitioned to SPA yet. (We have long-term plans to head in that direction, and I don't expect the transition to affect our module structure much - outside of main, of course, but main modules are a small fraction of our total modules.)

We have a top-level module namespace called Nri for things specific to our UI, as opposed to things that we might open-source someday (e.g. the Analytics module, the Emoji module, etc). Here's an example of three related ones:

Nri.QuizHeader.Model
Nri.QuizHeader.Styles
Nri.QuizHeader.View

So our Quiz Header has a model, and a view, and some elm-css styles. (We've been migrating from Sass to elm-css and it's been sweet!) We don't have a Nri.QuizHeader.Update because the quiz header doesn't have any state. I think this is worth emphasizing, because I see people create a model/update/view any time they want to reuse code, and I think that's the wrong way to scale. Unnecessary state management is bloat! We had no need for an update function here, so it was simpler not to have one.

Plenty of times we just have a module to hold view, and plenty of others it's not even a separate module, it's just a plain old function inside an existing module, e.g. viewSidebar : User -> Html msg

We also have reusable views that are used across multiple pages, for example:

Nri.Tabs
Nri.TextInput
Nri.Toggleable
Nri.Tooltip

All of these are stateful, and their APIs looks like github.com/evancz/elm-sortable-table - they do not define their own Msg types, and callers don't have to use Cmd.map. Their states are super simple, and defining their own Msg types would have been overkill - more trouble than it was worth. This is also worth emphasizing; immediately reaching for a custom Msg and Cmd.map any time local state is involved is a surefire way to get needlessly overcomplicated wiring.

My rule of thumb is that reusable views where view returns Html msg instead of Html Msg are nicer by default, and I only reach for a custom Msg once I have enough state transitions that Cmd.map would reduce verbosity substantially.

Finally we have some reusable data structures, which begin with Data., for example:

Data.Assignment
Data.Assignment.Decoder

We debated the right namespace for these and settled on Data because what they have in common is that they're about representing and encoding/decoding some piece of data.

These are a mix of various union types and type aliases that represent common data structures in our app. Some of them have a lot going on, so it's decently common to have a data structure defined in one module, and then the decoder and/or encoder in a separate module. It's no big deal if they live in the same module, though. Again, we don't spend a ton of time on module structure because it's so easy to change reliably if we change our minds.

Hope that helps!