Firma del metodo di aggiornamento in radice aggregata - DDD

Question

Firma del metodo di aggiornamento in radice aggregata - DDD

#1 da (0 voti)

0

Come dovrebbe sembrare la firma del metodo di aggiornamento nella radice aggregata? Ad esempio, ho bisogno di aggiornare l'indirizzo dell'utente. Ho diversi modi per farlo e non so quale sia il migliore ("domain driven design way"). Il primo modo è creare un metodo in User che ottenga UserAddress come argomento:

public void updateAddress(UserAddress address) {
    // update logic
}

Ma in questo caso i componenti esterni che utilizzano User.updateAddress (indirizzo UserAddress), conoscono la rappresentazione interna dell'indirizzo dell'utente.

L'altro modo è creare metodi con molti argomenti:

public void updateAddress(String city, String street, String country) {
     //update logic    
}

Oppure posso creare qualche oggetto valore:

public void updateAddress(AddressDTO addressDto) {
    // update logic
}

Qual è il modo migliore?

public class User {
    private Long id;
    private List<UserAddress> addresses;
    // other fields and methods
}

public class UserAddress {
    private Long id;
    private String type;
    private Boolean isMain;
    private Address address;

    public void update(Address address, Boolean isMain) {}
}

public class Address {
    // fields like city, street etc
}

domain-driven-design java

posta Damian U 05.09.2017 - 10:32

fonte

1 risposta

Leggi altre domande sui tag domain-driven-design java

Come creare un corretto gestore di argomenti per il software CLI? Il modo giusto per l'accodamento di attività ridondanti?

score 0 · Accepted Answer

Which way is better?

Per quanto ne so, non c'è una sola risposta semplice a questo.

All'interno del modello di dominio; è una buona idea esprimere i tuoi dati come Value Objects invece di esporre semplicemente i tipi primitivi usati per rappresentarli. Ciò significa che la firma delle entità dovrebbe normalmente essere espressa in termini di valori, non di tipi primitivi.

Le radici aggregate sono in genere solo entità che si trovano nella posizione radice del loro aggregato. Quindi normalmente sollevi la stessa API.

Tuttavia, esiste una vera questione relativa al passaggio dei dati attraverso il confine a il modello e se si debba o meno trattare la radice aggregata come vivente al confine o all'interno di essa.

La scelta abituale è che la radice viva all'interno del confine - che l'applicazione è responsabile per disporre i dati nella forma corretta prima di passarli al modello.

Questo è spesso conveniente per la convalida dell'input; se l'applicazione è responsabile della definizione dei dati, è nella posizione migliore per decidere come gestire gli input non validi.

Questo suggerisce

public void updateAddress(City city, Street street, Country country) {
    //update logic    
}

o

public void updateAddress(CityName city, StreetName street, CountryName country) {
    //update logic    
}

anziché

public void updateAddress(String city, String street, String country) {
     //update logic    
}

Ad esempio, se esamini Cancro entità dal DDDSample , noterai che tutti i metodi sono espresso in altri tipi di modello. I tipi di dati primitivi sono generalmente limitati a valori come UNLOCODE .