java - Best practice of designing JPARepository(ies) for ORM Domain graph -

i have been designing spring rest apis using standard mvc architecture domain layer pojos , repositories fetch domain data db tables. far these entities isolated design acted separate restcontroller, service, , repository flow each entity. have been looking understand best practice when comes association in domain objects i.e., orm. example, lets take following pseudocode illustrate domain classes (only purpose express design in question. have not provided complete classes):

public class customer {     @column     private int id;      @column;     private string name;      @onetomany     private list<order> orders;      //...getters setters }  public class order {     @column     private int id;      @column;     private string ordernumber;      @onetomany     private list<product> products;      @manytoone     private customer customer;      //...getters setters }   public class product {     @column     private int id;      @column;     private string productname;      @manytoone     private order order;      //...getters setters } 

the dilemma have designing perspective. have following approaches incorrect:

1. define 1 restcontroller customer , provide api resources /customers, /customers/id/orders, /customers/id/orders/id/products etc. have 1 service takes care of working these domains. have separate jparepository each domain. "keep simple" thing here have separete repository each domain have provide query methods in corresponding repository class in order find details specific domain i.e., fetch orders given customer id. however, makes me think killing purpose of using orm model because fetching individual domains through repository classes. option make 3 repository classes wired in service class , think not design. 3 might looks okay here have 6 7 domains in orm graph in actual requirements mean autowiring 6 repositoris in 1 service class.

2. one restcontroller , 1 service class in above option repository class single too. repository created customer domain. in way retrieve customers other domaims lazy loaded. fulfil request of "/customers". fulfil request of "/customers/id/orders" again use customer repository, retrieve customer given id , return list of orders. further, request of "/customers/id/orders/id/products" , require writing manual data fetching mechanism in customer domain takes care of retrieving list of products given customerid , orderid. way use 1 repository, satisfying purpose of using orm adding manual fetching data methods in customer domain. negative see need complete list of orders in customer domain if have customerid , orderid available. have fetched 1 single order based on customerid , orderid has used separate repository order.

3. both incorrect , there exists better approach.

i have looked through spring docs repository , hibernate docs orm. went through multiple tutorials one-to-many mappings spring data rest found mixed approaches in different tutorials.

this question duplicate have read multiple posts on stackoverflow regarding design concern none of answers give me reasoning trade offs , options mentioned above. hence, reposting question.

it mixed approach. e.g. in case product entity need not have @manytoone relation order. imagine if product part of 1 million orders! how many time query product find orders? query findordersbyproduct(product) rather findproductbyorder(order)

1. think w.r.t usecase. makes sense have 1 directional mapping if never fetch information other owner of relationship

2. think amount of data fetch (including joins) if query entity.

3. e.g if fetching organization need fetch employees? system go toss (lazy loading save of time if have angular bind , fetch entire model). make sense have many 1 relationship org employee entity.