Comunicazione tra livelli in DDD

Question

Comunicazione tra livelli in DDD

#1 da (1 voti)

8

Leggendo la letteratura di DDD ho trovato i seguenti livelli:

Application Mondo Outsider (Controllers, Crons, ecc.)
Application Services (o UseCases) - che orchestra più servizi di dominio o servizi di infrastruttura. Sono chiamati da Outside World . Sanno cosa devono essere fatte le cose
Domain Services - che contiene come sono fatte le cose (affidandosi alle interfacce del repository)

Domanda : esistono delle best practice su come comunicare tra i livelli?

Quello che so: - Application services deve restituire "i dati desiderati" da mostrare e alcuni "successi" della transazione (avvertenze, errore, informazioni) - I dati restituiti da Application Service devono essere raccolti da Domain Services e / o Infrastructure Services e composti da togather.

Controller <-> Application Service <-> Domain Service          
                                   <-> Infrastructure Service

Questi sono alcuni dei miei pensieri ambigui:

tutti i metodi su Application Service hanno un DTO specifico che contiene la "richiesta" come parametro? Come AddItemToCardCommandDto (che racchiudeva tutti i dati necessari). Che ne dici di un generico ResultObject che ha solo un paio di metodi come getResult e hasErrorrs o getMessages ?
Come devono restituire DomainService dati ed errori? Dovrebbero restituire errori per eccezione? Sembra strano perché per me la convalida dei bussines deve essere chiamata in DomainServices in quanto fanno parte delle regole aziendali.

domain-driven-design

posta user237329 31.05.2016 - 10:15

fonte

1 risposta

Leggi altre domande sui tag domain-driven-design

Come testare le modifiche alla configurazione in un servizio? Come gestire la fusione di progetti di Visual Studio

score 1 · Answer 1

Direi che avere DTO diluirebbe il design del Modello. Possiamo evitare di dover utilizzare DTO rifattorizzando il nostro modello e progettando le nostre API per utilizzare gli oggetti dei modelli refactored.

La risposta alla query 1: Il servizio dell'applicazione può avere metodi con una firma

void addItemToCard(Item item, Card card);

I metodi possono avere un tipo restituito o meno, in base al tipo di operazione che stiamo cercando di eseguire e ai dati che vogliamo trasferire attraverso i livelli. Devi assicurarti che ogni livello abbia un'interfaccia specificata e che i diversi livelli si parlino l'un l'altro attraverso quell'interfaccia per tutti i componenti nell'applicazione.

Ad esempio:

List<Items> getItemsOnCard(String cardID);
//returns list of items or empty list if no item can be found.

List<Offers> getOffersApplicableOnCardForItem()
//should return list of Offers or empty list if no item can be found. Should not return a null if no items can be found

Assicurarsi che tutti i metodi siano conformi allo stesso comportamento è più importante per mantenere l'interfaccia intatta.

Rispondi alla query 2:

Penso che DDD raccomandi di avere 3 strati se lo ricordo bene. Avere intelligenza di dominio nel livello dell'applicazione aiuta e significa che la tua applicazione è legata al dominio e ha un contesto limitato. Potresti aggiungere livelli aggiuntivi se ritieni che 3 non sia sufficiente. Le eccezioni possono essere utilizzate per sovrapporre le informazioni tra i vari livelli. I dati possono essere contenuti all'interno di segnaposti di eccezioni personalizzate per le aziende.

Spero che questo risponda ad alcune delle domande che hai.