Dovresti iniziare con la modellazione dei casi d'uso e la modellazione dei processi, ma mai con i diagrammi delle classi.
I processi ti diranno in che modo le entità si relazionano l'una con l'altra.
In realtà, non hai bisogno di tutte le tue classi persistenti in un diagramma di solito - non c'è una storia dietro a questo! È una bella foto di famiglia, forse sarebbe bello aiutare a tracciare gli elementi del sistema in un secondo momento, ma di solito ti viene detto, come regola generale, che un diagramma UML non dovrebbe mai contenere più di 15 elementi, in quanto rende facile sbagliare la progettazione .
Immagina il tuo sistema come un cubo di Rubik. Per capire come risolvere il cubo di Rubik, di solito guardi uno, due o tre lati. Non appiattisci il cubo!
Ogni singolo diagramma dovrebbe raccontare una storia sul tuo sistema: forse dice la tassonomia di una famiglia di classi, forse dice come il sistema viene usato dai diversi attori, forse dice come viene giocato un determinato scenario, forse indica come un determinato insieme di oggetti interagisce tra loro per risolvere un problema o come un componente è strutturato internamente.
Ecco perché di solito dovresti avere molti piccoli diagrammi: forse potresti chiedere a uno strumento speciale di riunirli, ma dal momento che sei un essere umano, e la maggior parte dei tuoi compagni di lavoro sono anche umani, non sarai mai in grado per cogliere l'intero sistema in una sola volta.
Una delle maggiori sfide nell'ingegneria del software (al contrario di altre metodologie, come Agile) è accettare che il tuo cranio sia limitato. Che tu possa afferrare circa 10 + -5 cose, e questo è quanto. O devi ingrandire o ridurre, nascondere i dettagli, devi girare il cubo o fare qualcosa in generale.
Devo ancora trovare un'applicazione che sia stata progettata come un unico, enorme diagramma di classe e che non contenga errori di progettazione gravi, visibile solo guardando il diagramma per 10 minuti o, più spesso, guardando il changelogs, dove si dovevano apportare modifiche serie.
Di solito dico alle persone di disegnare i flussi di dati per ciascuno dei casi d'uso: quali dati arrivano, quali dati vengono fuori, quali dati sono necessari per ottenere i risultati. Quindi chiedi che tipo di punti dolenti possono esserci per ogni passo.
Riprese di un grande ritratto di famiglia di classi persistenti - questo è piuttosto limitato. Ovviamente, dovresti raccogliere le classi necessarie per essere mantenute su questi diagrammi di flusso, ma forse è meglio se uno strumento lo fa per te.
Il design non riguarda come risolvere una particolare implementazione. Affrontalo più tardi. Per prima cosa, scopri, che tipo di lezioni hai bisogno. Una classe UML è un costrutto astratto: potrebbe anche non tradurre mai per le classi Java mai. Una classe UML è solo un modo di dire: "beh, avremo cose che hanno queste caratteristiche significative dal nostro attuale punto di vista". Una classe Java è un modo per dire alla macchina come allocare memoria e per quale scopo.
Una volta che UML ti dice ciò che ti serve, solo allora puoi iniziare a pensare a come realizzarlo.
E sì, usa Domain-Driven Design (il libro blu con lo stesso titolo è abbastanza carino).
(E so che sarò incolpato dai ragazzi Agile che non sono abbastanza agile, ma non ci occupiamo di questo, stiamo parlando di UML: la maggior parte dei ragazzi che fanno Agile non ha mai veramente capito UML, e loro non vogliono preoccuparsi di questa domanda che spero.)