DDD Servizi o iniezione di costruttore

Question

Nella letteratura Design Dominio guidata è spesso detto che i servizi di dominio dovrebbero essere apolidi.

Credo che la ragione di ciò sia perché le chiamate di servizio dovrebbero rappresentare singole unità di lavoro. Non ci dovrebbe essere uno stato di servizio che più metodi di servizio userebbero.

Rompi questa regola nell'architettura del servizio in modo che io possa costruire iniettare tutti i repository rilevanti richiesti nel servizio. Esempio:

public class UserService : IUserService
{
    public IUnitOfWork UnitOfWork { get; set; }

    public IUserRepository UserRepository { get; set; }

    public ICustomerRepository CustomerRepository { get; set; }

    public UserService(IUnitOfWork unitOfWork, IUserRepository userRepository, ICustomerRepository customerRepository)
    {
        UnitOfWork = unitOfWork;
        UserRepository = userRepository;
        CustomerRepository = customerRepository;
    }

    public User RegisterNewUser(...)
    {
        // Perform relevant domain logic
    }

    // ...
}

.

Per poter utilizzare l'iniezione del costruttore sul UserService, avrei bisogno di avere lo stato (proprietà) in modo che i metodi di servizio abbiano accesso ai repository pertinenti e tali.

Sebbene spero di progettare i singoli metodi di servizio come unità di lavoro isolate, non posso necessariamente impedire che accada.

Come potrei I Architecture Domain Services in modo che siano apolidi? è anche necessario?

Modifica:

Eric Evans in Design guidato da dominio: Affrontare la complessità Nel cuore del software :

.

Quando un processo o una trasformazione significativa nel dominio non è un Responsabilità naturale di un oggetto di entità o valore, aggiungere un'operazione al modello come interfaccia standalone dichiarata come servizio. Definisci il interfaccia in termini di lingua del modello e assicurati che il Il nome dell'operazione è parte del linguaggio onnipresente. Fai il servizio Stayless .

Vaughn Vernon raccomanda anche servizi apolidi nel suo libro Implementazione Design guidato dominio .

Answer 1

Un modo per avvicinarsi al tuo obiettivo è iniettare un contenitore di IOC nella classe di servizio, quindi sovrascrivere la tua proprietà ottenere metodi per risolvere un'istanza della classe necessaria.La tua nuova classe sembrerebbe qualcosa del genere:

public class UserService : IUserService
{
  private IUnitOfWork UnitOfWork 
  { 
    get{return container.Resolve<IUnitOfWork>()}
  }
  private IUnityContainer container {get;set;}

  public UserService(IUnityContainer container )
  {
    this.container = container;
  }

  public User RegisterNewUser(User user)
  {
     //Domain logic
  }

}

.

La tua classe di servizio ora ha una dipendenza da un contenitore IOC che non è una buona cosa, ma se stai cercando di avvicinarsi a un servizio apolidi, questo lo farebbe.

Answer 2

Mi sembra che confondi avendo proprietà con lo stato.

UserService è un servizio. Solo ha readonly ( rimuovi le proprietà dei setter ) che sono servizi apolidi, come IUserRepository. Questo rende UserService stesso un servizio di apolidi.

Sì, potremmo persino aggiungere un servizio di livello superiore in cima, che ha un IUserService come uno dei suoi componenti. Anche quel servizio sarebbe stato apolida.

Perché, chiedi?

Lo scopo (o almeno A scopo) dell'oscivelità è di consentire l'inversione del controllo: riteniamo il controllo su quali casi otteniamo all'esterno. Se qualcun altro sta controllando quali casi otteniamo, allora quegli istanze erano migliori essere apolidi! Cosa succede se otteniamo lo stesso istanza che un'altra classe sta ottenendo, e anchiamo entrambi alterando il suo stato? Il risultato sarebbe indeterminato.

Chiaramente, questo problema è evitato se i nostri servizi non hanno proprietà, forse UserRepository, forse. Avviso anche che è ugualmente ben evitato quando un servizio di livello superiore, ad esempio UserService, ha esclusivamente proprietà readonly di tali servizi, perché non c'è nulla da assegnare. Possiamo riposare il servizio che il servizio iniettato si comporterà sempre correttamente, poiché non esiste uno stato nella sua gerarchia per farlo dipendere da.