Come strategia di base, eviterei quasi sempre di archiviare lo stesso pezzo di informazione in due diversi posti / classi di un modello di dati, che conduce troppo facilmente a codice non gestibile. Se inizi ad avere attributi come   numberOfMonths    in due classi (come è stato suggerito in un'altra risposta), possono deviare gli uni dagli altri, potresti dover scrivere codice per impedirlo, devi preoccuparti di quale sia la versione "principale" di quell'attributo potrebbe dover duplicare la documentazione e così via. 
 Una soluzione che hai suggerito era  "Un campo genitore in modo che possiamo attraversare il backup dell'oggetto per ottenere i dati" . Va bene quando  nel tuo dominio aziendale  ogni oggetto   PaidByItem    è correlato in qualche modo a un   Xyz    e a un   Aaa    oggetto. Quindi ha senso esprimere quella relazione anche nel codice con un riferimento: 
public class PaidByItem {
    int feeAmount = 100;
    Xyz xyz; // lets assume this is Java or C#, so a reference, no copy!
    AAA aaa;
    // ...
    public double totalAmount (){
        return  feeAmount * xyz.numberOfMonths / aaa.daysPerYear;
    }
}
 I nomi non sensoriali come   Xyz    o   Aaa   , tuttavia, non ci dicono molto sul vero dominio. Ci possono essere molti motivi per cui non vuoi introdurre una dipendenza da   Xyz    o   Aaa    in   PaidByItem   . Ad esempio, potrebbero portare a una dipendenza ciclica da evitare, oppure questo tipo di relazioni / riferimenti semplicemente non ha alcun senso dal punto di vista del dominio. In questi casi, spesso è preferibile utilizzare l'altro suggerimento  "Una classe di calcolo separata per ottenere i dati, eseguire il calcolo e restituire un valore ". In alternativa, puoi cambiare il design in 
    public double totalAmount (int numberOfMonths, int daysPerYear){
        return  feeAmount * numberOfMonths / daysPerYear;
    }
 che significa che il chiamante di questo metodo ha la responsabilità di assicurarsi che le funzioni   totalAmount    vengano chiamate con i parametri corretti dagli oggetti giusti. L'ultima opzione ha più senso quando non è richiesto che quei parametri come   numberOfMonths    provengano da uno specifico oggetto di riferimento. 
 TLDR: evita l'archiviazione ridondante, scegli la soluzione che rappresenta il tuo dominio aziendale in modo più appropriato.