DDD sem monitoração de estado Serviços e Construtor de Injeção

Question

Em Domain Driven Design, literatura, costuma-se dizer que os serviços de domínio deve ser apátrida.

Acredito que a razão para isso é porque as chamadas de serviço deve representar uma unidade de trabalho.Não deve haver qualquer serviço do estado que vários métodos de serviço usaria.

Eu quebrar essa regra no meu arquitetura de serviço para que eu possa construtor injetar todos os repositórios necessários no serviço.Exemplo:

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
    }

    // ...
}

Para me usar construtor de injeção no UserService, Eu precisaria ter estado (propriedades), de modo que os métodos de serviço ter acesso ao repositórios e tal.

Embora eu espero que a concepção individual de métodos como unidades isoladas de trabalho, eu não necessariamente impedir que isso aconteça.

Como eu poderia arquitetura serviços de domínio, de modo que eles são apátridas? Isso é mesmo necessário?

EDITAR:

Eric Evans no Domain-driven Design:Lidar com a Complexidade no Coração do Software:

Quando um significativo processo ou transformação no domínio não é um natural de responsabilidade de uma ENTIDADE ou OBJETO de VALOR, adicione uma operação para o modelo de interface autônomo declarado como um SERVIÇO.Definir o interface em termos da linguagem do modelo e certifique-se de que o nome da operação faz parte da LINGUAGEM universal.Fazer o SERVIÇO sem monitoração de estado.

Vaughn Vernon também recomenda stateless serviços em seu livro A Implementação De Domain Driven Design.

Answer 1

Uma forma de chegar perto de seu objetivo é injetar um contêiner IOC em sua classe de serviço, em seguida, substituir os métodos de obtenção de propriedade para resolver uma instância necessária de classe.Sua nova classe seria algo parecido com isto:

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
  }

}

Sua classe de serviço agora tem uma dependência em um contêiner IOC, que não é uma coisa boa, mas se você está tentando se aproximar de um estado de serviço, isto iria fazê-lo.

Answer 2

Parece-me que confundem a presença de propriedades com tendo estado.

UserService é um serviço.Ele só tem acesso somente leitura (por favor, remova os setters as propriedades que são apátridas serviços, tais como IUserRepository.Isso faz UserService si um estado de serviço.

Sim, nós poderíamos até mesmo adicionar um nível mais alto de serviço na parte de cima, que tem um IUserService como um de seus componentes.De serviço, que, também, seria sem monitoração de estado.

Por que, você pergunta?

A propósito (ou, pelo menos, um finalidade) da apatridia é permitir a Inversão de Controle:nós abrir mão do controle sobre o que instâncias temos para o lado de fora.Se alguém está controlando instâncias temos, então essas instâncias tinha melhor ser sem estado!O que se conseguirmos a mesma instância de outra classe está chegando, e nós dois começam a alterar o seu estado?O resultado seria indeterminado.

Claramente, este problema é evitado, se os nossos serviços, não têm propriedades - como UserRepository, talvez.Observe também que é igualmente evitados quando um nível mais alto de serviço, tais como UserService, exclusivamente, tem propriedades só de leitura de tais serviços, porque não há nada para associar.Temos certeza de que a injetado serviço será sempre comportar-se corretamente, como não há estado em sua hierarquia para dele depender.