Having tried a few different ways, I actually think it's a good thing to separate the resources and have come to value the discipline imposed by no cyclic dependencies between resources. The key is separating resources (managing state and logic about say users) and handlers (responding to http requests about users). So there are a few reasons you might want a resource to know about another one - so it can populate a list of joined resources (like tags on a page), so you can update other resources, so you can check something on another resource (like user permissions). While it is tempting to do this, I think it leads you down a path where all your resources are intimately tied together, which inhibits reuse, and more importantly makes it hard to know where a resource might have been mutated or what effect something like page.Update() will actually have.

The position I've come to is that it's better to keep resources isolated, and then allow handlers to pull in resources as they need them and either show or modify them explicitly in the handler. So this means handlers need to be in a separate package (I use a subpackage of the resource package to keep it all together). This has a few advantages:

• Resources are limited to only knowing about themselves, so you are sure there is no dependency or modification between resources.
• Handlers can be grouped with the resources they act on, and typically will only act on those ones, though if necc. there will be exceptions (say update a page record if a page image changes).
• Tying resources together happens only in handlers, so they choose how to connect and filter sub-resources.
• Actions on resources like mutating state happens explicitly in handlers.

The other objection to this is stutter, but I think if you typically use users.New() or users.Find() rather than users.User{} it's not a huge issue, and to me it's not a huge deal, other people might object more strongly to that. I think the advantages outweigh the disadvantages for the particular apps I'm making (web apps), but of course for different projects and people there are different trade-offs. I'm not convinced there is one-size fits all for package guidelines, but it is interesting to hear how other people structure their projects, particularly larger ones. Some problems with organisation only really show up when the project is large enough.