DDD: creazione di moduli riutilizzabili e distinzioni del tipo di servizio (dominio, infrastruttura, applicazione)

Are Domain Services merely an Interface which exist to provide a layer of abstraction between the Infrastructure Layer and your Model? ie: Repositories + HashingServices, etc.

Le responsabilità dei servizi di dominio comprendono diverse cose. La più ovvia è la logica abitativa che non si adatta a una singola entità. Ad esempio, potrebbe essere necessario autorizzare un rimborso per un determinato acquisto, ma per completare l'operazione sono necessari i dati dall'entità Purchase , Customer entità, CustomerMembership entità.

I servizi di dominio forniscono anche le operazioni necessarie al dominio per completare la sua funzionalità come PasswordEncryptionService , ma l'implementazione di questo servizio risiederà nel livello infrastruttura dal momento che sarà per lo più una soluzione tecnica.

I servizi di infrastruttura sono servizi che quindi un'operazione di infrastruttura come l'apertura di una connessione di rete, la copia di file dal file system, la comunicazione con un servizio Web esterno o la conversazione con il database.

I servizi di applicazione sono l'implementazione di un caso d'uso nell'applicazione che stai creando. Se si annulla una prenotazione di un volo, si:

1. Interrogare il database per l'oggetto Reservation.
2. invoca Reservation- > cancel.
3. Salva oggetto in DB.

Il livello applicazione è il client del dominio. Il dominio non ha idea di quale sia il tuo caso d'uso. Espone semplicemente la funzionalità attraverso i suoi aggregati e servizi di dominio. Il livello dell'applicazione tuttavia rispecchia ciò che stai cercando di ottenere orchestrando i livelli di dominio e infrastruttura.

I mentioned having an Application Service which looks like this: Access/Application/Services/UserService::CreateUser(string name, string email, etc): User The method signature accepts primitive data type arguments and returns a new User Entity (not a DTO!).

PHP potrebbe non essere il posto migliore per iniziare a conoscere DDD dato che molti dei framework PHP là fuori (Laravel, Symfony, Zend, ecc.) tendono a promuovere RAD. Si concentrano maggiormente sul CRUD e sulla traduzione di forme in entità. CRUD! = DDD

Il tuo livello di presentazione dovrebbe essere responsabile della lettura degli input del modulo dall'oggetto richiesta e del richiamo del servizio dell'applicazione corretto. Il servizio applicativo creerà l'utente e invocherà il repository utente per salvare il nuovo utente. Opzionalmente è possibile restituire un DTO dell'utente al livello di presentazione.

How should separate modules handle unidirectional relationships. Should module A reference module B's application layer (as it's doing now) or the infrastructure implementation (via separated interface)?

Il modulo di parole nel gergo DDD ha un significato diverso da quello che stai descrivendo. Un modulo dovrebbe contenere concetti correlati. Ad esempio, un modulo ordini nel livello dominio potrebbe ospitare l'aggregato Ordine, l'entità OrderItem, OrderRepositoryInterface e MaxOrderValidationService.

Un modulo Ordine nel livello applicazione può ospitare OrderApplicationServie, CreateOrderCommand e OrderDto.

Se parli di livelli, ogni strato dovrebbe preferibilmente dipendere dalle interfacce di altri livelli, quando possibile. Lo strato di presentazione dovrebbe dipendere dalle interfacce del livello dell'applicazione. Il livello applicazione dovrebbe fare riferimento alle interfacce dei repository o dei servizi di dominio.

Personalmente non creo interfacce per entità e oggetti valore perché credo che le interfacce debbano essere correlate a un comportamento, ma YMMV:)

Do Application Layer Services require a Separate Interface? If the answer is yes then where should they be located?

Dipende :) per applicazioni complesse costruisco interfacce coz applichiamo rigorosi test di unità, integrazione e accettazione. L'accoppiamento lento è fondamentale qui e le interfacce si trovano nello stesso livello (livello applicazione).

Per la semplice app che costruisco direttamente sui servizi dell'app.

Risposta breve a una lunga domanda, ma vedo il modello come segue

Regola 1: gli oggetti di dominio dovrebbero avere una singola radice di aggregazione

Regola 2: i root aggregati non dovrebbero essere troppo grandi, dividere le cose in contesti limitati

Problema: i root aggregati diventano presto troppo grandi e non esiste un modo chiaro per tracciare una linea tra i vari modelli di dominio in essi contenuti

Soluzione: servizi di dominio. Crea interfacce che puoi iniettare in Modelli di Dominio che consentono loro di fare cose al di fuori del loro Dominio di Dominio o Radice Aggregata.

Quindi penso che direi che i tuoi esempi sono solo servizi / repository normali, IDatabaseRepositoryForStoringUsers o IGenericHashingCode

Un servizio di dominio consente la comunicazione tra contesti limitati. vale a dire

User.UpgradeAccount(IAccountService accountService)
{
    accountService.UpgradeUsersAccount(this.Id);
}

Dove utenti e account si trovano in percorsi separati / contesti limitati.

Se l'utente e l'account si trovano nella stessa radice di aggregazione, dovresti naturalmente essere in grado di fare:

User.UpgradeAccount()
{
    this.MyAccount.Upgrade();
}

Non sono del tutto chiaro dalla tua domanda su come stai integrando la roba su Application / Infrastructure e il modulo. Se non si desidera realmente alcuna referenza incrociata tra contesti limitati, inserire le proprie Interfacce di servizio dominio nel proprio modulo che non fa riferimento a nessun altro Contesto Limitato. limitandoti a esporre i tipi di valori di base o solo i DTO perhapse