title: DDD Stateless Services and Constructor Injection
body: <p>In Domain Driven Design literature it is often said that domain services should be stateless.</p>
  
  <p>I believe the reason for this is because service calls should represent single units of work.  There shouldn't be any service state which multiple service methods would use. </p>
  
  <p>I break this rule in my service architecture so that I can constructor inject all the relevant repositories required in the service.  Example:</p>
  
  <pre><code>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
      }
  
      // ...
  }
  </code></pre>
  
  <p>In order for me to use constructor injection on the <code>UserService</code>, I would need to have state (properties) so that the service methods have access to the relevant repositories and such.  </p>
  
  <p>Although I hope to design the individual service methods as isolated units of work, I cannot necessarily prevent that from happening.</p>
  
  <p><strong>How could I architecture domain services so that they are stateless?</strong>  Is this even necessary?</p>
  
  <p><strong>EDIT:</strong></p>
  
  <p><strong>Eric Evans</strong> in <a href="https://rads.stackoverflow.com/amzn/click/com/0321125215" rel="nofollow noreferrer" rel="nofollow noreferrer">Domain-driven Design: Tackling Complexity in the Heart of Software</a>:</p>
  
  <blockquote>
    <p>When a significant process or transformation in the domain is not a
    natural responsibility of an ENTITY or VALUE OBJECT, add an operation
    to the model as standalone interface declared as a SERVICE. Define the
    interface in terms of the language of the model and make sure the
    operation name is part of the UBIQUITOUS LANGUAGE. Make the SERVICE
    <strong>stateless</strong>.</p>
  </blockquote>
  
  <p><strong>Vaughn Vernon</strong> also recommends stateless services in his book <a href="https://rads.stackoverflow.com/amzn/click/com/0321834577" rel="nofollow noreferrer" rel="nofollow noreferrer">Implementing Domain Driven Design</a>.</p>