Non esistono domande idiote, solo risposte stupide :D

Secondo me non esiste un'unica soluzione, dipende dal sistema che vuoi ottenere.
Un primo metodo potrebbe essere di esporre sulla classe Utente una Collection di Address e due istanze di tipo ShippingInfo e PersonalInfo. Se tratti Utente come un "semplice" DTO potresti limitarti ad esporli come normali properties e lasciare alla logica dell'applicazione il compito di istanziarle ed usarle.

Un altro sistema potrebbe essere di non legare affatto le classi, ma inserire in quelle accessorie un riferimento all'utente (l'ID ad esempio). In pratica una volta ottenuto l'istanza di Utente, usi una classe manager per leggere (ad esempio) gli Address che sono collegati a quell'Utente in base all'ID. Praticamente è un modello moooolto marcato su una struttura DB.

Un'altra alternativa è usare un sistema di Component-Based entities, qualcosa tipo questo: http://entropyinteractive.com/2011/02/game-engine-design-component-based-entities/
ma credo che così complicheresti troppo le cose :)

Per quel poco che ho capito di architettura e pattern, la separazione è utile quando i moduli sono diversi, in questo caso mi sembra di restare sempre all'interno del modulo "anagrafica"... Quale sarebbe l'utilità della DI?!

Mi sono espresso male, non la intendevo la separazione in layer e/o il ricorso a sorgenti dati fake, ma l'uso della D.I./I.O.C. o interfacce in classi cosi legate tra loro.
Non credo che utente, address, shipping etc. vengano gestite da moduli separati dell'applicazione, mentre un eventuale classe order potrebbe essere in un modulo separato ed allora l'uso della D.I./I.O.C. O di interfacce sarebbe auspicabile