In DDD, un servizio di dominio è essenzialmente solo un modello di facciata e / o mediatore?

9

In Domain Driven Design, il Domain Layer può avere diversi servizi (tradizionali). Ad esempio, per il dominio Utente, potremmo avere:

  • Una UserFactory, che costruisce gli oggetti Utente in modi diversi
  • Un UserRepository, che è responsabile dell'interazione con i servizi di persistenza nel livello infrastruttura

Un UserService nel livello di dominio è semplicemente un mediatore e / o facciata per questi due servizi e il livello di infrastruttura, o c'è ancora dell'altro?

    
posta e_i_pi 21.12.2017 - 04:33
fonte

2 risposte

5

Domain services è meglio descritto da ciò che non sono:

  • non sono né EntitiesAggregate roots
  • non sono Value objects
  • trasportare la conoscenza del dominio che non si adatta in modo naturale solo una Entity o una Value object

Un esempio di Domain service è un Saga/Process manager : coordina un processo di lunga durata che coinvolge più Aggregate roots , possibile da diversi Bounded contexts .

Detto questo, quale è un Domain service e come è implementato sono due cose ortogonali.

Is a UserService in the Domain Layer simply a Mediator and/or Facade to those two services and the Infrastructure Layer, or is there more to it?

Alcuni servizi di dominio come UserRepository (composto da un'interfaccia definita in Domain layer e un'implementazione concreta in Infrastructure layer ) può essere implementato usando il modello di progettazione Facade . Altri servizi di dominio non lo sono.

Non esiste una regola rigida su come per implementarli, oltre alla regola importante che Domain layer non deve dipendere da altri livelli (e wikipedia.org/wiki/SOLID_(object-oriented_design)">SOLID).

    
risposta data 21.12.2017 - 08:07
fonte
1

Vedo servizi in DDD come risultato di Inversione di dipendenza .

Se dovessi utilizzare dipendenze "semplici", il tuo codice di dominio chiamerebbe il database per salvare o interrogare un'entità, o fabbrica, che crea un'entità, che è legata al database o al servizio esterno o qualche tipo di altro codice di infrastruttura .

Ma non è così che dovrebbe essere il codice del dominio. Il codice di dominio non dovrebbe dipendere dal codice di infrastruttura. Poiché questa dipendenza rende più difficile testare e, eventualmente, riutilizzare. È per questo che inverti questa dipendenza. Fai in modo che il codice dell'infrastruttura dipenda dal codice del dominio. E per farlo, devi introdurre un'astrazione. Un'astrazione che definisce quale comportamento il codice di dominio si aspetta venga implementato dall'infrastruttura.

E i servizi in DDD sono quell'astrazione. Nella maggior parte dei casi, per i codici di dominio, tali servizi dovrebbero essere interfacce semplici. E l'implementazione dovrebbe essere nel codice dell'infrastruttura, che ha dipendenza da quelle interfacce.

    
risposta data 21.12.2017 - 08:43
fonte