DDD, creando un aggregato al di fuori del livello di servizio dell'applicazione

Question

DDD, creando un aggregato al di fuori del livello di servizio dell'applicazione

#1 da (1 voti)

1

Ho un servizio (webservice) che viene utilizzato per accedere alla logica del dominio. Uno dei metodi del webservice è createFoo, dove Foo è il mio aggregato. Quindi la classe che implementa il metodo del webservice chiama il mio servizio di applicazione che contiene il metodo createFoo che è responsabile di fare alcune cose e persistere della nuova istanza di Foo.

Questa nuova istanza di Foo viene restituita dal servizio dell'applicazione alla classe che implementa il metodo del servizio web. Infine, l'istanza di Foo viene convertita in qualcosa come FooWsResponse e quindi il servizio Web restituisce l'istanza di FooWsResponse.

In questo momento tutto questo è più o meno implementato in questo modo:

public class CreateFooService{

    private FooService appService;

    private Converter<Foo, FooWsResponse> converter;

    public FooWsResponse createFoo(CreateFooParams params){
        Foo foo = FooFactory.createFoo(params);
        foo = appService.createFoo(foo);
        return converter.converter(foo);
    }
}

Il problema con il codice sopra è che il metodo Application Service è fuorviante perché non sta creando un'istanza di Foo, sta solo lavorando sulla logica del dominio associata alla creazione di Foo e alla persistenza dell'istanza.

Quindi, le cose che voglio sapere sono:

Va bene creare l'aggregazione al di fuori del livello di servizio ?. So che posso passare a CreateFooParams come parametro appService.createFoo ma non voglio farlo perché il mio livello di servizio sarà accoppiato al framework dei servizi web. Inoltre, non voglio passare tutte le proprietà della classe CreateFooParams come parametri di appService.createFoo perché finirò con un metodo con 15 parametri !. Infine, creando l'istanza di Foo prima di chiamare il metodo appService.createFoo ma ora il nome del metodo non è accurato e anche tutti i client del mio appService dovrebbero creare come creare un'istanza di Foo per passarlo come parametro di appService.createFoo che è molto male e può portare a molti problemi.
Devo creare un FooDto che riceva tutti i dati di CreateFooParams e lo passi al metodo appService.createFoo ?. Questa sembra un'opzione migliore, ma avere 3 classi diverse con quasi le stesse proprietà si sente molto ridondante

Voglio sapere qual è la cosa giusta da fare secondo le linee guida DDD.

Grazie per il tuo aiuto.

design domain-driven-design

posta Orposuser 18.11.2013 - 01:02

fonte

1 risposta

Leggi altre domande sui tag design domain-driven-design

Aggiunta trasparente di un livello di interfaccia del database Distribuzione uniforme attraverso una catena di risorse

score 1 · Accepted Answer

In generale, direi di no. Gli aggregati non devono lasciare il limite del modello di dominio e qualsiasi logica aziendale relativa alla creazione dell'aggregato deve risiedere all'interno di tale aggregato.
Ti consigliamo di aggiungere un metodo factory a quella classe di aggregazione che include tutti i parametri necessari per creare una nuova istanza di tale aggregato. Se c'è una logica aziendale legata a quella creazione, dovrebbe risiedere in quel metodo di fabbrica.
Se ritieni di aver bisogno di molti parametri per quel metodo di produzione, allora forse è un segno che quell'aggregato potrebbe essere troppo grande (forse).
Non capisco davvero perché dovresti creare e poi restituire immediatamente quell'istanza. Di solito, si separano le letture e le scritture, perché i modelli di lettura e scrittura sono in genere molto diversi.