Un servizio di dominio dovrebbe avere dipendenze?

I was under the impression that a Domain Model should not have dependencies injected (even repositories).

Sì, è vero.

Should a Domain service have dependencies? I realise that application services have repositories injected.

Ecco cosa ha scritto Evans

A good SERVICE has three characteristics

• The operation relates to a domain concept that is not a natural part of an entity or value object
• The interface is defined in terms of other elements of the domain model
• The operation is stateless

Statelessness here means that any client can use any instance of a particular SERVICE without regard to the instance's individual history. The execution of a service will use information that is accessible globally, and may even change global information (that is, it may have side effects).

Più avanti, affronta la tua domanda, anche se in modo un po 'obliquo

But we are still left with calls to SERVICES in the interbank networks. What's more, in most development systems, it is awkward to make a direct interface between a domain object and external resources. _We can dress up such external SERVICES with a FACADE that takes inputs in terms of the model....

Il servizio di dominio (facciata) avrebbe una dipendenza dal servizio esterno.

Detto questo; guardando indietro di 10 anni dopo, non sono sicuro che abbia ottenuto i dettagli di questo diritto. Quando interagisci con lo stato che è distribuito da qualche altra parte, quel altrove potrebbe non essere disponibile. La comunicazione distribuita non riesce e, se questo non fa parte del tuo dominio, la logica per la gestione di tali errori inizia a intralciare.

Gary Bernhardt e Cory Benfield hanno entrambi tenuto discorsi molto interessanti sulla separazione delle preoccupazioni sull'effetto collaterale da quelle del modello.

Un modello che trasforma gli input in output è semplice da ragionare; un modello che trasforma gli input in output e gli effetti collaterali, non è più semplice.

Abbiamo bisogno di chiarire alcuni concetti importanti da DDD. Quindi:

Ogni applicazione DDD può essere divisa logicamente in due parti:

1. La parte write / command, in cui si eseguono le modifiche agli oggetti persistenti. Qui vivi il Aggregates e tutto ciò di cui hanno bisogno per fare il loro lavoro, cioè tutto il loro Value objects . Questo è indicato in letteratura come "il modello di dominio".

2. Il lato di lettura / interrogazione in cui si mostrano gli oggetti persistenti o qualche proiezione di essi. Qui rimangono le interfacce domain services e Repository .

Ci sono anche i gestori di Sagas / Process che collegano le due parti.

I have read Eric Evans book. I was under the impression that a Domain Model should not have dependencies injected (even repositories).

Sì, sono d'accordo. Questo si riferisce alla parte Write della tua applicazione (ad esempio Aggregates ).

Should a Domain service have dependencies? I realise that application services have repositories injected.

Sì, possono avere .

1) The domain model tell the application service that the customer is entitled to offer a, b and c. Then the application service goes to the database and gets the offers

Non domain model ma domain service . Questo è strettamente un problema di read side (se usi queste informazioni per visualizzarle all'utente o in una Saga).

2) The domain model (domain service?) goes to the database and gets details of the offers and returns them to the application service as a list of DTOs.

Il servizio di dominio e non il modello, come ho scritto nel paragrafo precedente. Questo dipende molto da quanto si vuole ottimizzare la velocità del recupero della persistenza poiché si può fare uso dell'ottimizzazione della persistenza e non recuperare l'intero documento / riga ma solo i dati necessari. Essendo sul lato della lettura ti è "permesso" di fare tutti i tipi di ottimizzazioni.

In ogni caso, la logica relativa alla selezione di tali offerte dovrebbe rimanere nel livello dominio.

P.S. c'è l' CQRS architettura / modello che si basa su questa separazione di lettura e scrittura.

Se il servizio di dominio è un intermediario tra clienti e offerte, come una funzione che restituisce le offerte idonee, forse il servizio applicativo utilizzerà il servizio di dominio per selezionare dal repository?

L'interfaccia per il repository può / dovrebbe vivere nel livello Dominio, quindi l'implementazione per il repository potrebbe essere iniettata nel servizio di dominio.

Un modello di dominio e estendiamolo a qualsiasi modello in generale, non dovrebbe avere dipendenze iniettabili.

Un dominio (factory) è costruito all'interno del dominio e avrà un'iniezione del costruttore in qualsiasi implementazione software non banale. Il minimo da iniettare è tipicamente il servizio di infrastruttura (EF, Dapper, ADO? (Il DTO in genere vivi qui). Il massimo? Tutto ciò che il dominio ha accesso a (facciate, progetti stand alone, altre fabbriche / servizi di dominio, ecc. ..).

Puoi quindi lanciare un'interfaccia in fabbrica, collegarla in DI e iniettarla in questo modo estrapolando le sue (molte?) dipendenze, finché non avrai una rete intricata di interdipendenze che troverai nella maggior parte dei casi. architettura aziendale.