Design Patterns by Erich Gamma et al is an excellent book that distills the experience of a whole bunch of developers and analysts. The whole field of patterns is more or less what you're describing. Analysis Patterns by Martin Fowler does something similar, but it's mostly for really, really big systems, like accounting and healthcare systems. Hmm... and Code Complete by Steve McConnell(?) offers some good stuff, too, although he talks about *modules* as opposed to *objects*.

The only other rule that I know is... practice being wrong frequently. As I'm quite sure you know, there's no trick to understanding large projects, just experience and finding out what works for you. People break down projects into smaller bits because projects get too large to keep in your head all at once. So, experiment with different breakdowns for a system, since there's no one right answer.

Think on paper. If you're visual, draw diagrams. If you're language-oriented, scribble notes. Some people keep Legos on their desks to build little models. Once you've got it out of your head, show it around to other people, who can sometimes see flaws. ("Um, why're you subclassing by gender? They've got the same methods, how about making it an attribute?")

System design is not a science, and there are no hard-and-fast procedures. Since I'm a linguistic thinker, I generally start by scribbling down a description of the problem, then start scribbling a list of classes that I think would help to solve it. Once I get bored with that, I take the objects I've got and scribble some notes indicating how they'll all interact to solve the problem that the system's supposed to solve, and add and subtract objects as needed. Then I take another look at my list of objects and see if some need to be broken down further. Then I take a few of the most central, important-seeming objects, and take a crack at developing 'em. Generally, this suggests some more classes, so I jot them down. Sometime around here I start bugging my coworkers/friends about whether my design looks vaguely good, or if I'm off the deep end again, and they'll say nice things like, "Stephen, it only needs to accept credit cards. You didn't need to write a whole new language."

Sorry to ramble... too much tea...