Zustandslose DDD-Dienste und Konstruktorinjektion

Question

In der Literatur zum domänengesteuerten Design wird oft gesagt, dass Domänendienste zustandslos sein sollten.

Ich glaube, der Grund dafür ist, dass Serviceeinsätze einzelne Arbeitseinheiten darstellen sollten.Es sollte keinen Dienststatus geben, den mehrere Dienstmethoden verwenden würden.

Ich breche diese Regel in meiner Servicearchitektur, damit ich alle relevanten Repositorys, die für den Service erforderlich sind, konstruktiv einfügen kann.Beispiel:

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
    }

    // ...
}

Damit ich die Konstruktorinjektion auf dem verwenden kann UserService, müsste ich einen Status (Eigenschaften) haben, damit die Servicemethoden Zugriff auf die relevanten Repositorys und dergleichen haben.

Obwohl ich hoffe, die einzelnen Servicemethoden als isolierte Arbeitseinheiten zu gestalten, kann ich das nicht unbedingt verhindern.

Wie könnte ich Domänendienste so gestalten, dass sie zustandslos sind? Ist das überhaupt notwendig?

BEARBEITEN:

Eric Evans in Domaingesteuertes Design:Bewältigung der Komplexität im Herzen der Software:

Wenn ein bedeutender Prozess oder eine Transformation in der Domäne nicht a ist natürliche Verantwortung einer ENTITÄT oder eines WERTOBJEKTS, fügen Sie eine Operation hinzu zum Modell als eigenständige Schnittstelle, die als DIENST deklariert ist.Definieren Sie die schnittstelle in Bezug auf die Sprache des Modells und stellen Sie sicher, dass die der Operationsname ist Teil der ALLGEGENWÄRTIGEN SPRACHE.Machen Sie den SERVICE Staatenlose.

Vaughn Vernon empfiehlt in seinem Buch auch staatenlose Dienste Implementierung von domänengesteuertem Design.

Answer 1

Eine Möglichkeit, Ihrem Ziel nahe zu kommen, besteht darin, einen IOC-Container in Ihre Serviceklasse einzufügen und dann Ihre Eigenschaftenabrufmethoden zu überschreiben, um eine Instanz der erforderlichen Klasse aufzulösen.Ihre neue Klasse würde ungefähr so aussehen:

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
  }

}

Ihre Serviceklasse ist jetzt von einem IOC-Container abhängig, was keine gute Sache ist, aber wenn Sie versuchen, einem zustandslosen Service näher zu kommen, würde dies ausreichen.

Answer 2

Es scheint mir, dass Sie Eigenschaften mit Zustand verwechseln.

UserService ist eine Dienstleistung.Es hat nur schreibgeschützt (bitte entfernen sie die setter) Eigenschaften, die zustandslose Dienste sind, wie z IUserRepository.Das macht UserService selbst ein staatenloser Dienst.

Ja, wir könnten sogar einen übergeordneten Service hinzufügen, der eine hat IUserService als eine seiner Komponenten.Auch dieser Dienst wäre staatenlos.

Warum, fragst du?

Der Zweck (oder zumindest a zweck) der Staatenlosigkeit ist es, die Umkehrung der Kontrolle zu ermöglichen:wir geben die Kontrolle über welche Instanzen wir bekommen nach außen.Wenn jemand anderes kontrolliert, welche Instanzen wir bekommen, dann sollten diese Instanzen besser staatenlos sein!Was ist, wenn wir dieselbe Instanz erhalten, die eine andere Klasse erhält, und wir beide beginnen, ihren Status zu ändern?Das Ergebnis wäre unbestimmt.

Dieses Problem wird natürlich vermieden, wenn unsere Dienste keine Eigenschaften haben - wie UserRepository, vielleicht.Beachten Sie auch, dass es ist ebenso gut vermieden wenn ein übergeordneter Dienst, wie z UserService, hat ausschließlich schreibgeschützte Eigenschaften solcher Dienste, da es nichts zuzuweisen gibt.Wir können sicher sein, dass sich der injizierte Dienst immer korrekt verhält, da es in seiner Hierarchie keinen Status gibt, von dem er abhängen könnte.