title: Where to validate pagination logic in domain driven design?
body: <p>In DDD, where should validation logic for pagination queries reside? 
  For example, if the service layer receives a query for a collection with parameters that look like (in Go), though feel free to answer in any language:</p>
  
  <pre><code>// in one file
  package repositories
  
  type Page struct {
     Limit int
     Offset int
  }
  
  // Should Page, which is part of the repository 
  // layer, have validation behaviour?
  func (p *Page) Validate() error {
     if p.Limit &gt; 100 {
        // ...
     }
  }
  
  type Repository interface {
    func getCollection(p *Page) (collection, error)
  }
  
  
  
  // in another file
  package service
  
  import "repositories"
  
  type Service struct {
    repository repositories.Repository
  }
  
  // service layer
  func (s *Service) getCollection(p *repositories.Page) (pages, error) {
      // delegate validation to the repository layer?
      // i.e - p.Validate()
  
      // or call some kind of validation logic in the service layer
      // i.e - validatePagination(p)
  
      s.repository.getCollection(p)
  }
  
  func validatePagination(p *Page) error {
    if p.Limit &gt; 100 {
      ...
    }
  }
  </code></pre>
  
  <p>and I want to enforce a "no <code>Limit</code> greater than 100" rule, does this rule belong in the Service layer or is it more of a Repository concern? </p>
  
  <p>At first glance it seems like it should be enforced at the Repository layer, but on second thought, it's not necessarily an actual limitation of the repository itself. It's more of a rule driven by business constraints that belongs on the entity model. However <code>Page</code> isn't really a domain entity either, it's more a property of the Repository layer. </p>
  
  <p>To me, this kind of validation logic seems stuck somewhere between being a business rule and a repository concern. Where should the validation logic go?</p>