While most view it as a sacrilege, I suppose, I use a skeleton MFC structure. Now that preference aside, I have my major interfaces to Direct3D kept as members of my application's window class which is inherited from CFrameWindow. It handles all my major coordination of rendering. My application specific surfaces like my tiles and such are stored in classes that represent that object type. For instance CTile allows me to code behavior specific for that object type as well as provide access to its surface.
I probably dragged this out too much! If I was using winapi style code I probably would still do a similar construction as I described above: wrap my major interfaces and surfaces into a scene managment class stored in main and my other surfaces into classes that cooresponded to their object's function. I like the idea that a class can hold data, manipulate, and store it "behind the scene" so to speak, and the querying class does not have to know about what was going. You can't really guarantee this kind of relationship with global data so I avoid use of globals. Some poeple still aren't real big fanatics of the object oriented style but I think its incredibly powerfull, IMHO. I long answer, but does that answer you're question?