You should start with use case modeling and process modeling, but never with class diagrams.
Processes will tell you how the entities relate to each other.
In fact, you don't need all your persistent classes in one diagram usually - there's no story behind that! It's a nice family picture, perhaps it'd be good to help trace system elements later, but you are usually told, as a rule of thumb that an UML diagram should never contain more than 15 elements, as it makes design errors easy to miss.
Imagine your system as a Rubik's cube. In order to understand how to solve the Rubik's cube, you usually look at one, two, or three sides. You don't flatten the cube out!
Every single diagram should tell a story about your system: perhaps it tells the taxonomy of a family of classes, perhaps it tells how the system is used by the different actors, perhaps it tells how a certain scenario is played, perhaps it tells how a certain set of objects interoperate with each other in order to solve a problem, or how a component is structured internally.
That's why you usually should have a lot of small diagrams: perhaps you could ask a special tool to bring them together, but since you're a human, and most of your workmates are also humans, you'll never be able to grasp the whole system at once.
One of the biggest challenges in software engineering (as opposed to other methodologies, like Agile) is to accept that your own skull is limited. That you can grasp around 10+-5 things, and that's it. You either have to zoom in or out, hiding details, you have to turn the cube, or do something in general.
I'm yet to find an application which was started designed as a single, huge class diagram and didn't contain serious design errors, visible just by looking at the diagram for 10 minutes, or - more usually - looking at the changelogs, where serious changes were had to be made.
I usually tell people to draw the data flows for each of the use cases first: what data comes in, what data goes out, what data is needed in order to get the results. Then ask what kind of pain points there can be for each step.
Shooting a big family portrait of persistent classes - this is rather limited. Of course, you should collect the classes needed to be persisted over these flow diagrams, but perhaps it's better if a tool does it for you.
Design is not about how to solve a particular implementation. Deal with that later. First,find out, what kind of classes you need. An UML class is an abstract construct: it might not even translate for Java classes ever. An UML class is just a saying: "well, we will have things which have these meaningful features from our current viewpoint". A Java class is a way to tell the machine how to allocate memory and for what purpose.
Once UML tells you what you need, then, only then you can start thinking about how to realize this.
And yes, use Domain-Driven Design (the blue book with the same title is quite nice).
(And I know I'll be blamed by the Agile guys that I'm not Agile enough, but let's not deal with this, we're talking about UML. Most of the guys who do Agile never really understood UML, and they don't want to care about this question I hope.)
