DDD repositories in application or domain service

Question

I m studying DDD these days, and I m having some questions concerning how to manage repositories with DDD.

Actually, I have met two possibilies :

First one

The first way of manage services I've read is to inject a repository and a domain model in an application service.

This way, in one of the application service methods, we call a domain service method (checking business rules) and if the condition is good, the repository is called on a special method to persist / retrieve the entity from the database.

A simple way of doing this could be :

class ApplicationService{

  constructor(domainService, repository){
    this.domainService = domainService
    this.repository = repository
  }

  postAction(data){
    if(this.domainService.validateRules(data)){
      this.repository.persist(new Entity(data.name, data.surname))
    }
    // ...
  }

}

Second one

The second possibility is to inject the repository inside of the domainService instead, and to only use the repository through the domain service :

class ApplicationService{

  constructor(domainService){
    this.domainService = domainService
  }

  postAction(data){
    if(this.domainService.persist(data)){
      console.log('all is good')
    }
    // ...
  }

}

class DomainService{

  constructor(repository){
    this.repository = repository
  }

  persist(data){
    if(this.validateRules(data)){
      this.repository.save(new Entity(data.name))
    }
  }

  validateRules(data){
    // returns a rule matching
  }

}

From now, I m not able to distinguish which one is the best (if there's one best) or what they imply both in their context.

Can you provide me example where one could be better than the other and why ?

Answer 1

The short answer is - you can use repositories from an application service, or a domain service - but it is important to consider why, and how, you are doing so.

Purpose of a Domain Service

Domain Services should encapsulate domain concepts/logic - as such, the the domain service method:

domainService.persist(data)

does not belong on a domain service, as persist is not a part of the ubiquitious language and the operation of persistence is not part of the domain business logic.

Generally, domain services are useful when you have business rules/logic that require coordinating or working with more than one aggregate. If the logic is only involving one aggregate, it should be in a method on that aggregate's entities.

Repositories in Application Services

So in that sense, in your example, I prefer your first option - but even there there is room for improvement, as your domain service is accepting raw data from the api - why should the domain service know about the structure of data?. In addition, the data appears to only be related to a single aggregate, so there is limited value in using a domain service for that - generally I'd put the validation inside the entity constructor. e.g.

postAction(data){

  Entity entity = new Entity(data.name, data.surname);

  this.repository.persist(entity);

  // ...
}

and throw an exception if it's invalid. Depending on your application framework, it may be simple to have a consistent mechanism for catching the exception and mapping it to the appropriate response for the api type - e.g. for a REST api, return a 400 status code.

Repositories in Domain Services

Notwithstanding the above, sometimes it is useful to inject and use a repository in a domain service, but only if your repositories are implemented such that they accept and return aggregate roots only, and also where you are abstracting logic that involves multiple aggregates. e.g.

postAction(data){

  this.domainService.doSomeBusinessProcess(data.name, data.surname, data.otherAggregateId);

  // ...
}

the implementation of the domain service would look like:

doSomeBusinessProcess(name, surname, otherAggregateId) {

  OtherEntity otherEntity = this.otherEntityRepository.get(otherAggregateId);

  Entity entity = this.entityFactory.create(name, surname);

  int calculationResult = this.someCalculationMethod(entity, otherEntity);

  entity.applyCalculationResultWithBusinessMeaningfulName(calculationResult);

  this.entityRepository.add(entity);

}

Conclusion

The key here is that the domain service encapsulates a process that is part of the ubiquitous language. In order to fulfill its role, it needs to use repositories - and it's perfectly fine to do so.

But adding a domain service that wraps a repository with a method called persist adds little value.

On that basis, if your application service is expressing a use case that calls for only working with a single aggregate, there is no problem using the repository directly from the application service.

Answer 2

There is problem with accepted answer:

Domain model is not allowed to depend on repository and domain service is part of domain model -> domain service should not depend on repository.

What you should do instead is assemble all your entities that are needed for business logic execution already in application service and then just provide your models with instantiated objects.

Based on your example it could look like this:

class ApplicationService{

  constructor(domainService, repository){
    this.domainService = domainService
    this.repositoryA = repositoryA
    this.repositoryB = repositoryB
    this.repositoryC = repositoryC
  }

  // any parsing and/or pre-business validation already happened in controller or whoever is a caller
  executeUserStory(data){
    const entityA = this.repositoryA.get(data.criterionForEntityA)
    const entityB = this.repositoryB.get(data.criterionForEntityB)

    if(this.domainService.validateSomeBusinessRules(entityA, entityB)){
      this.repositoryC.persist(new EntityC(entityA.name, entityB.surname))
    }
    // ...
  }
}

So, rule of thumb: Domain model does not depend on outer layers

Application vs Domain service From this article:

• Domain services are very granular where as application services are a facade purposed with providing an API.

• Domain services contain domain logic that can’t naturally be placed in an entity or value object whereas application services orchestrate the execution of domain logic and don’t themselves implement any domain logic.

• Domain service methods can have other domain elements as operands and return values whereas application services operate upon trivial operands such as identity values and primitive data structures.

• Application services declare dependencies on infrastructural services required to execute domain logic.

Answer 3

Neither of your patterns are good unless your services and objects encapsulate some coherent set of responsibility.

First of all say what your domain object is and talk about what it can do within the domain language. If it can be valid or invalid why not have this as a property of the domain object itself?

If for example the objects validness only makes sense in terms of another object then maybe you have a responsibility 'validation rule X for domain objects' which can.be encapsulated in a set of services.

Does validating an object necessitate storing it within your business rules? Probably not. The 'storing objects' responsibility normally goes in a separate repository object.

Now you have an operation you want to perform which covers a range of responsibilities, create an object, validate it and if valid, store it.

Is this operation intrinsic to the domain object? Then Make it part of that object ie ExamQuestion.Answer(string answer)

Does it fit with some other part of your domain? put it there Basket.Purchase(Order order)

Would you rather do ADM REST services? Ok then.

Controller.Post(json) 
{ 
    parse(json); 
    verify(parsedStruct); 
    save(parsedStruct); 
    return 400;
}

Answer 4

Thinking about Dependency Inversion Principle, and also the Interface Segregation Principle : the notion of Interface is more a client code concern ! Meaning the client code has a specific need of an external service, that then it gets via an Interface that is specific to its needs, not more, not less. Which means that, this is the client code (team) that keeps master (or "owner") of this Interface definition.

Here, if we have an Application1, it may not needs the same exact Interface definition that an Application2, in order to access the RepositoryXxx implementation ! So the Interface IRepositoryXxx definition could potentially not be the same for each of these applications, that act as client code to this Interface. So each Application could have its "own" Interface definition for its proper needs of access to the RepositoryXxx.

And as the Domain Layer should always be Application agnostic, keeping being exploitable by any Applications(use cases needs). It would NOT be logic to keep any of those Interfaces IRepositoryXxx into the Domain layer because these Interfaces could be specific for each given Application ! And there we are : i wouldn't put the IRepository Interfaces into the Domain Layer, because they are not part of its concerns, it's a use case concern, so a specific Application concern and need. I would put these Interfaces into the Application Layer, OR a specific layer between Domain And Application layer, for the sake of keeping opened and reusable.

Keeping therefore, more S.O.L.I.D. .

Now, if the Domain Layer really needs to access a Repository, i think it should have its own IRepository Interface, but not sharing it or exposing it to the externals layers.

So each one its needs, each one its Interfaces, following SOLID : DIP and ISP.