References daughters and service pattern

5

A heavily used pattern in DDD , is service pattern .

My question is, where is the logic for references to "daughters"?

For example, a use case, Pedido that has Produtos

public class Pedido 
{
  public int Id {get;set;}
  public int ClienteId {get;set;}
  public Cliente Cliente {get;set;}
  public ICollection<PedidoProduto> Produtos {get;set;}
}

public class PedidoProduto
{
  public int Id {get;set;}
  public int PedidoId {get;set;}
  public int ProdutoId {Get;set;}

  public Pedido Pedido {get;set;}
  public Produto Produto {get;set;}
}

Let's go to a Controller Action

public ActionResult Create(Pedido model, int[] Produtos) 
{
   //Lógica...
}
Well ... the logic of handling the request and its Products goes within PedidoService , thus leaving only my Controller dependence with only 1 Service , and within PedidoService have dependency of PedidoRepository and ProdutoRepository , or is there a need to create 2 Service and make Controller depend on 2 Service ?

    
asked by anonymous 09.10.2015 / 01:07

2 answers

1

The scenario you are presenting is a scenario of a Aggregate , so the logic should always be called from the Service Request, the request service has access to your items. And it does not make much sense to be able to call the order items separately from the order.

    
20.10.2015 / 15:29
0

Good question. The responsible for the heavy part of the logic must be Service, the Service Pattern idea is to group a set of operations of a given context and make them available through its interface to the client layers, in this case it must have N Repository. Imagine an application that should be consumed in different ways, such as a REST service and Socket, for example, Services would offer application interfaces on their interfaces so that clients (REST and Socket) would handle issues pertaining to their protocol.

Take a look at here

    
16.10.2015 / 02:57