DDD - Camada de Aplicação e injeção de dependência

[fernando mondo]

Sabendo que no DDD a camada de aplicação é uma Façade e que com injeção de dependencia eu devo em seu construtor passar as entidades de Domínio para ela, como eu injeto um serviço da aplicação em meu serviço de apresentação?

Em Mvc

HomeController: Controller
{
        private readonly IHomeService _homeService;
        public HomeController(IHomeService homeService)
        {
            _homeService = homeService;
        }

        public ActionResult Index(ClienteModel model)
        {
            _homeService.FazAlgo(model);         
            return View(model);
        }
}

class HomeService
{
   void FazAlgo(ClienteModel  model){
   Cliente c = new Cliente(model.nome, model.Cpf ...);  
   var s = new ServicoAplicacao(c);
   s.FazUmaCoisa();
   } 
}

Ou sej, como vou fazer para injetar a dependencia de um serviço da camada de aplicação no construtor de deu HomeService?:

class HomeService
{
  public HomeService(ServicoAplicacao servicoAplicacao)
   {
     _servicoAplicacao = servicoAplicacao;
   }

   void FazAlgo(ClienteModel  model){
      Cliente c = new Cliente(model.nome, model.Cpf ...);   
  
      _servicoAplicacao.FazUmaCoisa(c);
    } 
}

Atualmente meus serviços de aplicação não recebem as entidades do dominio no construtor e sim nos métodos, é uma forma de injeção de dependencia válida, mas acabo tendo eu um serviço da aplicação diversos métodos recebendo os mesmo parametros:

public class ServicoAplicacao{
  
  public void FazUmaCoisa(Cliente c) { ... }
  public void FazOutra(Cliente c) { ... }
  public void FazEMaisUma(Cliente c) { ... }

 }

Como vocês fazem?

[Alessandro de Souza]

Esta definição não está correta. Em DDD a camada de aplicação não precisa necessariamente implementar o padrão Façade.

E entidades de domínio não são injetadas na camada de aplicação, ela simplesmente tem acesso ao MODEL.

O que deve ser injetado são os serviços, repositórios etc....

Att,

Alessandro

--
Você recebeu esta mensagem porque faz parte do grupo .Net Architects hospedado no Google Groups.
Para postar envie uma mensagem para dotnetar...@googlegroups.com
Para sair do grupo envie uma mensagem para dotnetarchitec...@googlegroups.com
Para mais opções visite o grupo em http://groups.google.com/group/dotnetarchitects?hl=pt-br

[Fernando Mondo]

Mas a aplicação não irá criar a entidade de dominio ela receberá da minha camada de apresentação. então se um servico da camada de aplicação tiver varios metodos que precisam das mesmas entidades eu deveria colocar no contrutor dele não?

Tem um Exemplo do Livro do Eric Evans que é assim:

//camada de aplicação:
public class FundTransfererService{
  
   public void Transferer(Account a, Account b, double value){ .. }
 
}

mas imagina que eu tivesse outros métodos nesta classe:

public class FundTransfererService{
  
  public void Transferer(Account a, Account b, double value){ .. }
  public void xxxxx(Account a, Account b, double value){ .. }
  public void yyyyyyy(Account a, Account b, double value){ .. }
  public void zzzzzzz(Account a, Account b, double value){ .. }
 
}


faz mais sentido eu receber Account a e  Account b no contrutor né?

mas daí na minha camada de apresentação, eu não vou querer dar um new no FundTransfererService porque se não eu não posso faze testes né? eu quero receber um FundTransfererService no contrutor tambem:


class HomeService
{
  public HomeService(FundTransfererService servicoAplicacao)

   {
     _servicoAplicacao = servicoAplicacao;
   }

   void FazAlgo(ClienteModel  model){
      Cliente c = new Cliente(model.nome, model.Cpf ...);   

   //ops só aqui é que eu tenho o cliente que eu preciso para o construtor
// acho que eu vou ter que dar um new mesmo não é?
//var  servicoAplicacao= FundTransfererService(c);
      _servicoAplicacao.FazUmaCoisa();
    } 
}

[Antonio Pedro]

Acho que você confundiu um Serviço de Domínio com Serviço da Camada de Aplicação.

O Exemplo que você cita é um serviço de domínio...

Outra coisa, serviços independente de utlilzar o DDD (exceto os de domínio que estão mais para objetos do que simples facades e são específicos do DDD), não devem possuir estado.

Por isso que o Alessandro falou "O que deve ser injetado são os serviços, repositórios etc...."

Att,

Antônio Nascimento

---

Date: Wed, 4 Apr 2012 13:31:49 -0300
Subject: Re: [dotnetarchitects] DDD - Camada de Aplicação e injeção de dependência
From: fernand...@gmail.com
To: dotnetar...@googlegroups.com

[Fernando Mondo]

[Igor]

Faço assim (Camada de Aplicação):

public class CargoService : ICargoService
    {
        private readonly ICargoRepository repository;

        public CargoService(ICargoRepository CargoRepository)
        {
            repository = CargoRepository;
        }

        public IList<CargoViewModel> ListaTodosOsCargos()
        {
            return Mapper.Map<List<Cargo>, List<CargoViewModel>>(repository.FindAll());
        }

        public void AdicionarUmCargo(CargoViewModel cargoViewModel)
        {
            Cargo cargo = Mapper.Map<CargoViewModel, Cargo>(cargoViewModel);
            repository.Add(cargo);
            repository.UnitOfWork.Commit();
        }

        public void AtualizarUmCargo(CargoViewModel cargoViewModel)
        {
            Cargo cargo = Mapper.Map<CargoViewModel, Cargo>(cargoViewModel);
            repository.Update(cargo);
            repository.UnitOfWork.Commit();
        }
}

E injeto o meu serviço da camada de applicação no meu controller:

public class CargoController : Controller
    {
        private readonly ICargoService service;

        public CargoController(ICargoService CargoService)
        {
            service = CargoService;
        }
}

As injeções são feitas com o Unity.

[Mário Meyrelles]

Esse é o jeito mais correto mesmo - ideal para se usar com um container de IoC e ideal para testar. Eu faria algo parecido. ***Talvez*** eu só venha a criar a interface quando for necessário testar ou criar uma segunda implementação. Isso porque na prática, você acaba diminuindo um pouco a velocidade de encontrar a implementação concreta do seu contrato. Tipo, "caracas, onde tá aquele cara que implementa o serviço?". 

Eu pessoalmente não gosto de sair criando interfaces que não sejam absolutamente úteis / necessárias. Não vejo problemas em criar uma instância concreta de um ICargoService e injetar...como provavelmente só tem um cara concreto mesmo... Aí eu evitaria uma abstração a mais e ficaria mais fácil entender o sistema para os novos integrantes da equipe. Mas é só uma opinião de quem pensa com praticidade acima de tudo.

[Fernando Mondo]

não faz sentido a camada de aplicação conhecer o ViewModel visto que este só existe no MVC.
Esta classe esta igual aos meus serviços da apresentação Mvc.

Os serviços da camada de aplicação devem conhecer é somente as entidades de Dominio.

[edmilson hora]

@Fernando, vc necessita se aprofundar um pouco mais.

ViewModel  não existe só no MVC, ViewModel é um conceito de classes que carregam os dados que serão exibibos pela View,  Pode-se usar ViewModel com WebForms, com Windows Forms, com WPF, com Silverlight, etc.   ViewModel  e DTO  são o mesmo conceito  classes  simples  que  trafegam dados  de um lugar para outro.

  No Exemplo que foi  dado, a camada de aplicação  tem que conhecer  a ViewModel sim, senão como é que  ela fara as transições  das Classes do Dominio  nas Classes  do ViewModel e Vice-Versa. 

---

De: Fernando Mondo <fernand...@gmail.com>
Para: dotnetar...@googlegroups.com
Enviadas: Quarta-feira, 4 de Abril de 2012 23:10
Assunto: Re: [dotnetarchitects] Re: DDD - Camada de Aplicação e injeção de dependência

[Fernando Mondo]

Só ah um motivo para a camada de aplicação conhecer ViewModel/Dto: Quando as camadas de apresentação serão feitas por terceiros e queremos esconder as classes de Domínio de fora do sistema.

Você até pode criar um ViewModel com wpf, silverlight etc, mas cada camada de apresentação pode ter seus próprios ViewModels (ou simplesmente não te-los).
ViewModel é um padrão onde sua classe DTO esta adaptada  diretamente para uma View e não o contrário.

O Objetivo da camada de aplicação é justamente pegar os dados através de sua tecnologia e transformar em entidades de domínio.

Caso contrário, você coloca uma camada a mais que muitas vezes não precisava (a não ser no caso que eu falei, quando queremos esconder o Dominio)

tipo, a ViewModel que a aplicação oferece provavelmente não será a mesma ViewModel que a minha aplicação mvc precisa (cada site tem suas características né).

Do mesmo modo, eu poderia pegar uma coleção de TextBox e DropDown do WebForms e vou ter que converter para sua ViewModel para depois ser transformado em entidade de Domínio. sendo que se eu conheço o Domínio poderia converter diretamente.

[edmilson hora]

@Fernando,

"Só ah um motivo para a camada de aplicação conhecer ViewModel/Dto: Quando as camadas de apresentação serão feitas por terceiros e queremos esconder as classes de Domínio de fora do sistema."

==> Não vou entrar em detalhes de quando se deve usar uma determinada abordagem, isso fica a cargo de cada um.

"Você até pode criar um ViewModel com wpf, silverlight etc, mas cada camada de apresentação pode ter seus próprios ViewModels (ou simplesmente não te-los)."

===> No Outro e-mail vc colocou que ViewModel só existe no MCV, agora vc chegou ao correto.

"ViewModel é um padrão onde sua classe DTO esta adaptada  diretamente para uma View e não o contrário."

===> Incorreto! não é bem isso não.

"O Objetivo da camada de aplicação é justamente pegar os dados através de sua tecnologia e transformar em entidades de domínio."

===> Mais ou menos, mas  não é só isso não, ela coordena  tudo nos  dois sentidos,  tanto no sentido da View  como no sentido das classes  do Dominio,  seria uma camada  de Coordenação,  tipo os Controllers do MCV.

"Caso contrário, você coloca uma camada a mais que muitas vezes não precisava (a não ser no caso que eu falei, quando queremos esconder o Dominio)"

===> Concordo que nem sempre a camada de aplicação é de vital importência, pode-se sim  consumir na camada de Apresentação, as Classes de Dominio, Repositório e Serviços, mas há casos em que o uso irá ajudar na manuteção.

"tipo, a ViewModel que a aplicação oferece provavelmente não será a mesma ViewModel que a minha aplicação mvc precisa (cada site tem suas características né)."

===> Se estamos falando de sites distintos claro, mas se estamos falando de um mesmo Projeto  onde  tem duas Camadas de Apresentação: WEB  e  Windows Forms,  a ViewModel  de uma serve exatamente para a outra.

"Do mesmo modo, eu poderia pegar uma coleção de TextBox e DropDown do WebForms e vou ter que converter para sua ViewModel para depois ser transformado em entidade de Domínio. sendo que se eu conheço o Domínio poderia converter diretamente."

====> Sim claro, pode-se fazer  direto, nem sempre a camada de aplicação é vital, coloquei isso logo acima.

Boa sorte,  e continue se aprofundado, alguns conceitos vc ainda esta  com dúvidas.

Abraços,

Edmilson

---

De: Fernando Mondo <fernand...@gmail.com>
Para: dotnetar...@googlegroups.com

Enviadas: Quinta-feira, 5 de Abril de 2012 7:52

[Igor]

@Mário Meyrelles
 
Eu mas no sentido de teste mesmo, também já sofri com esse mal de ter que procurar onde está a implementação da interface.
Mas elas são importantes para mim pois eu crio a estrutura deles e deixo a implementação dos códigos dos métodos para um segundo plano.

@Fernando mondo
Faz todo o sentido a minha aplicação conhecer o ViewModel.

A aplicação pode conhecer minhas viewsmodels para poder converte-las para entidades do dominio.
E outra, não faz sentido eu criar ViewModel para MVC e ter que criar outra para WPF.
Usa a mesma para os dois, e para o bind no WPF eu extendo a viewmodel padrão (reutilização de código).

A grande questão é que eu não gostei de ideia de jogar a minha entidade de dominio na visão. Entidades do dominio são do dominio, então eu tento blindar o maximo ele.

É claro que há projetos que você pode fazer isso, e vai fazer sentido, desde que ele seja pequeno para médio. Projetos grandes ficam inviaveis, pois se mudar algo na visão teria que mudar algo no dominio, desse jeito com Entidades e ViewModel, eu altero a view, uma vez que o dominio raramente muda.

E fora a facilidade para testar.

@Edmilson
Certissímo seu ponto de vista, penso assim tbm.

[Fernando Mondo]

" No Outro e-mail vc colocou que ViewModel só existe no MCV, agora vc chegou ao correto."

é que quando você colocou ViewModel eu achei que estava falando das do MVC e não uma genérica para qualquer tipo de camanda de apresentação

quando eu escrevi:

"O Objetivo da camada de aplicação é justamente pegar os dados através de sua tecnologia e transformar em entidades de domínio."

eu na verdade queria ter escrito:

"O Objetivo da camada de APRESENTAÇÂO é justamente pegar os dados através de sua tecnologia (viewmodel, textboxs etc) e transformar em entidades de domínio para entregar para a camade de APLICAÇÂO"

deve ter sido o sono...

eu vou ter que discordar de vocês, não faz sentido ter a aplicação conhecendo a ViewModel/DTO (a não ser, repito, quando você quer esconder o domínio)

Se você ler a documentação do Asp.Net Mvc ou mesmo o padrão de Projeto MVC vai ver que o M, V e C são todoas da camada de apresentação, os Model do Mvc tem dataannotations para configurar os Editors Tamplates e os Validators JQuery, alem disso você pode colocar Annotatons para o model Binder e é aconselhável tambem colocar propriedades como SelectList (que é do assembly Web.Mvc) para preencher seus selects da sua View. Coisa que não faz o menor sentido ter em uma ViewModel (DTO seria melhor) para windonsForms, ou mesmo Console Project.

[Igor]

Estamos falando de DDD?
Se sim, esqueça que o controller parece a camada de apresentação, pois ele não é.
Não os confundam. Como eu disse, se você vai querer fazer um software focado no dominio, o que é o mais importante?
O mais importante é proteger o seu dominio, daí que vem o conceito de isola-lo. Blindar o dominio é uma maneira de protege-lo.

Como eu irei usar DataAnnotation nas minhas entidades do dominio se eles tem que estar isoladas? Não faz sentido.

Como eu disse também ali em cima, eu uso das viewmodels para não levar as minhas entidades para a visão, e se eu quiser usar DataAnnotation por exemplo eu uso nos meus viewmodels, assim não mexendo no meu dominio.

[Fernando Mondo]

eu não disse de usar DataAnnotation nas entidades de Domínio, o que eu disse é que as ViewModel que usam DataAnnotation  (depende de qual, mas o Bind por exemplo) e SelectList só podem estar em projetos Web.Mvc.

[edmilson hora]

Desde que entendi o conceito de Interfaces na OOP  gostei de pensar na Interface como pertencente às Classes que a Implementam  e não às Classes que a consomem.
Logicamente uma interface pode ser consumida por diversas classes e muitas delas podem  não ter nada em comum além do fato de consumirem aquela interface. Já as classes  que implementam as interfaces geralmente tem mais  em comum que às que consomem, as que implementam normalmente fazem parte de um sub-set de classes pois sua característica mais marcante é o fato de implementarem os métodos  ou terem as propriedades ditadas pela Interface.  Sendo assim, eu sempre me refiro  à  Interfaces  tipo:  IProdutoRepository  como Interface de Infra  apesar  dela estar declarada no Domínio. 

Outros podem discordar  e alegar que a Interface IProdutoRepository é do Domínio pois ela esta declarada lá e pode ser implementada em qualquer  outro lugar inclusive dentro do Domínio  ou  fora  da Infra, o que acham??

[Igor]

@Edmilson

Faço exatamente assim. Declaro as interfaces de repositorios no meu dominio, mas elas são implementadas na infra.

[Lemol Lutonda]

Como assim? interfaces do Dominio s�o da Infra?
As coisas s�o de onde s�o declaradas (de onde s�o), ou de onde s�o usadas?

> From: edmilson hora
> Sent: Thursday, April 05, 2012 12:31 PM
> To: dotnetar...@googlegroups.com
> Subject: Re: [dotnetarchitects] Re: DDD - Camada de Aplica��o e inje��o de
> depend�ncia
>
>
> Desde que entendi o conceito de Interfaces na OOP gostei de pensar na

> Interface como pertencente �s Classes que a Implementam e n�o �s Classes

> que a consomem.
> Logicamente uma interface pode ser consumida por diversas classes e muitas

> delas podem n�o ter nada em comum al�m do fato de consumirem aquela
> interface. J� as classes que implementam as interfaces geralmente tem
> mais em comum que �s que consomem, as que implementam normalmente fazem
> parte de um sub-set de classes pois sua caracter�stica mais marcante � o
> fato de implementarem os m�todos ou terem as propriedades ditadas pela
> Interface. Sendo assim, eu sempre me refiro � Interfaces tipo:

> IProdutoRepository como Interface de Infra apesar dela estar declarada

> no Dom�nio.
>
> Outros podem discordar e alegar que a Interface IProdutoRepository � do
> Dom�nio pois ela esta declarada l� e pode ser implementada em qualquer
> outro lugar inclusive dentro do Dom�nio ou fora da Infra, o que acham??
>
> --
> Voc� recebeu esta mensagem porque faz parte do grupo .Net Architects

> hospedado no Google Groups.
> Para postar envie uma mensagem para dotnetar...@googlegroups.com
> Para sair do grupo envie uma mensagem para
> dotnetarchitec...@googlegroups.com

> Para mais op��es visite o grupo em
> http://groups.google.com/group/dotnetarchitects?hl=pt-br

Lemol-C
...não paro até chegar lá...

Participe en la XVI Convencion Cientifica de Ingenieria y Arquitectura del 26 al 30 de noviembre de 2012. La Habana, Cuba: http://ccia.cujae.edu.cu

Consulte la enciclopedia colaborativa cubana. http://www.ecured.cu

[Lemol Lutonda]

Igor, falando de DDD, o controller (do MVC) n�o � camada de apresenta��o?
de qu� � ent�o?

> From: Igor
> Sent: Thursday, April 05, 2012 12:22 PM
> To: dotnetar...@googlegroups.com
> Subject: [dotnetarchitects] Re: DDD - Camada de Aplica��o e inje��o de
> depend�ncia
>

> Estamos falando de DDD?
> Se sim, esque�a que o controller parece a camada de apresenta��o, pois ele
> n�o �.
> N�o os confundam. Como eu disse, se voc� vai querer fazer um software
> focado no dominio, o que � o mais importante?
> O mais importante � proteger o seu dominio, da� que vem o conceito de
> isola-lo. Blindar o dominio � uma maneira de protege-lo.

>
> Como eu irei usar DataAnnotation nas minhas entidades do dominio se eles

> tem que estar isoladas? N�o faz sentido.
>
> Como eu disse tamb�m ali em cima, eu uso das viewmodels para n�o levar as
> minhas entidades para a vis�o, e se eu quiser usar DataAnnotation por
> exemplo eu uso nos meus viewmodels, assim n�o mexendo no meu dominio.

[Igor]

Então, é relativo isso... Ele é parecido somente quando for para comandar execuções, mas de resto ele não tem todas as caracteristicas da camada de aplicação.

Se for um projeto pequeno (pequeno mesmo), nem nada mirabulante eu até consideraria que ele fosse a camada de apresentação. Mas aí não procuraria usar DDD.

Olha, eu uso a camada de aplicação como um façade, e tbm para coordernar execuções e tal, e pq eu não posso usar o Controller do MVC? Simplesmente pq a aplicação que eu desenvolvo tem 3 plataforma (digamos assim). Então eu tenho uma desktop, uma web e um mobile. Que usam a mesma camada Application. Essa minha application (pra confundir um pouco mais) lembra bastante a camada de Services do DDD.

[Lemol Lutonda]

Igor, � que no outro email voce afirmou que, falando de DDD o controller
(que quer dizer uma aplica��o ASP.NET MVC, por exemplo) n�o � camada de
apresenta��o. E eu pergunto � camada de que ent�o?

Com camada de Services, queres dizer camada de Aplica��o?

> From: Igor
> Sent: Thursday, April 05, 2012 2:54 PM
> To: dotnetar...@googlegroups.com

> Subject: Re: [dotnetarchitects] Re: DDD - Camada de Aplica��o e inje��o de
> depend�ncia
>

> Ent�o, � relativo isso... Ele � parecido somente quando for para comandar
> execu��es, mas de resto ele n�o tem todas as caracteristicas da camada de
> aplica��o.
>
> Se for um projeto pequeno (pequeno mesmo), nem nada mirabulante eu at�
> consideraria que ele fosse a camada de apresenta��o. Mas a� n�o procuraria
> usar DDD.
>
> Olha, eu uso a camada de aplica��o como um fa�ade, e tbm para coordernar
> execu��es e tal, e pq eu n�o posso usar o Controller do MVC? Simplesmente
> pq a aplica��o que eu desenvolvo tem 3 plataforma (digamos assim). Ent�o

> eu tenho uma desktop, uma web e um mobile. Que usam a mesma camada
> Application. Essa minha application (pra confundir um pouco mais) lembra
> bastante a camada de Services do DDD.
>
>

[Igor]

O MVC todo é parte da camada de Interface, ou User Interface.
E no outro eu quis dizer serviços da camada de aplicação. ;)

Imagina assim, eu tenho dois projetos um WPF e um MVC certo? Não posso assumir que o C do MVC será a camada de aplicação.
Logo MVC é só User Interface e o WPF tbm. E quem coordena é a Application.

Esse explicação está no site e é bem legal.

"The application services in the sample application are responsible for driving workflow and coordinating transaction management (by use of the declarative transaction management support in Spring). They also provide a high-level abstraction for clients to use when interacting with the domain. These services are typically designed to define or support specific use cases. See BookingService or HandlingEventService.

In some situations, e.g. when dealing with graphs of lazy-loaded domain objects or when passing services' return values over network boundaries, the services are wrapped in facades. The facades handle ORM session management issues and/or convert the domain objects to more portable Data Transfer Objects) that can be tailored to specific use cases. In that case, we consider the DTO-serializing facade part of the interfaces layer. See BookingServiceFacade for an example."

No caso eu uso ViewModel em vez de DTO.

[Fernando Mondo]

Voltei com mais indagações...

confesso que não entendi sobre o que o igor e o edmilson afirmaram de viewmodel na camada de aplicação..

mas enfim, a minha dúvida inicial eu resolvi com o uso de factory.

Atualmente o que eu tenho classes da aplicação que se parecem com isso:

public class LiberarContrato
{
 public LiberarContrato(Cliente cliente,Contrato contrato, IRepositorio, ILog){...}

 public void Liberar(string usuario, string senha)
 {
  try{
   _unidadeTrabalho.IniciarTrasacao();
   _provedorApi.CriarUsuario(usuario, senha);
   _contrato.TornarAtivo();
   _repositorioContrato.Add(_contrato);
   _notificador.EnviarEmail(_cliente);
   _unidadeTrabalho.Salvar();
  }
  catch(exception e)
  {
   _unidadeTrabalho.RollBack();
   _log.Gravar(e);
  }
}

}

Fica a dúvida então: Deveria esta classe ser um serviço do Domínio, já que eu tenho uma regra de negocio aqui dentro (ex: toda liberação exige criar um usuario numa api externa, tornar o contrato ativo e entiar email ao cliente)?

Outra: deveria Dominio (ou Aplicação) possuir a interface IProvedorApi já que elá é que usa (sabendo que eu vou implementá-la na infra)?

--
Você recebeu esta mensagem porque faz parte do grupo .Net Architects hospedado no Google Groups.

Para postar envie uma mensagem para dotnetar...@googlegroups.com
Para sair do grupo envie uma mensagem para dotnetarchitec...@googlegroups.com

Para mais opções visite o grupo em http://groups.google.com/group/dotnetarchitects?hl=pt-br

[Lemol Lutonda]

N�o entend� bem a l�gica (essa nomenclatura me confunde :( ), mas, pelo
que percebo, parte � Servi�o de Aplica��o e uma parte estaria em um
Servi�o de Dominio. Mas como disse, n�o entend� a l�gica...

Se voce est� achando que � regra de dominio, ent�o provavelmente tinha que
ser/estar um servi�o de dominio.

Atenciosamente,

Leza Morais Lutonda, Lemol-C
http://lemolsoft.webs.com
http://github.com/lemol
@lemolsoft on twitter

>
> From: Fernando Mondo
> Sent: Sunday, April 15, 2012 1:30 AM
> To: dotnetar...@googlegroups.com
> Subject: Re: [dotnetarchitects] Re: DDD - Camada de Aplica��o e inje��o de
> depend�ncia
>

> Voltei com mais indaga��es...
>
> confesso que n�o entendi sobre o que o igor e o edmilson afirmaram de
> viewmodel na camada de aplica��o..
>
> mas enfim, a minha d�vida inicial eu resolvi com o uso de factory.
>
> Atualmente o que eu tenho classes da aplica��o que se parecem com isso:

>
> public class LiberarContrato
> {
> public LiberarContrato(Cliente cliente,Contrato contrato, IRepositorio,
> ILog){...}
>
> public void Liberar(string usuario, string senha)
> {
> try{
> _unidadeTrabalho.IniciarTrasacao();
> _provedorApi.CriarUsuario(usuario, senha);
> _contrato.TornarAtivo();
> _repositorioContrato.Add(_contrato);
> _notificador.EnviarEmail(_cliente);
> _unidadeTrabalho.Salvar();
> }
> catch(exception e)
> {
> _unidadeTrabalho.RollBack();
> _log.Gravar(e);
> }
> }
>
> }
>

> Fica a d�vida ent�o: Deveria esta classe ser um servi�o do Dom�nio, j� que
> eu tenho uma regra de negocio aqui dentro (ex: toda libera��o exige criar

> um usuario numa api externa, tornar o contrato ativo e entiar email ao
> cliente)?
>

> Outra: deveria Dominio (ou Aplica��o) possuir a interface IProvedorApi j�
> que el� � que usa (sabendo que eu vou implement�-la na infra)?

>
>
>
> Em 5 de abril de 2012 15:56, Igor <oro...@gmail.com> escreveu:
>

> O MVC todo � parte da camada de Interface, ou User Interface.
> E no outro eu quis dizer servi�os da camada de aplica��o. ;)
>
> Imagina assim, eu tenho dois projetos um WPF e um MVC certo? N�o posso
> assumir que o C do MVC ser� a camada de aplica��o.
> Logo MVC � s� User Interface e o WPF tbm. E quem coordena � a
> Application.
>
> Esse explica��o est� no site e � bem legal.

>
> "The application services in the sample application are responsible for
> driving workflow and coordinating transaction management (by use of the
> declarative transaction management support in Spring). They also provide
> a high-level abstraction for clients to use when interacting with the
> domain. These services are typically designed to define or support
> specific use cases. See BookingService or HandlingEventService.
>
> In some situations, e.g. when dealing with graphs of lazy-loaded domain
> objects or when passing services' return values over network boundaries,
> the services are wrapped in facades. The facades handle ORM session
> management issues and/or convert the domain objects to more portable
> Data Transfer Objects) that can be tailored to specific use cases. In
> that case, we consider the DTO-serializing facade part of the interfaces
> layer. See BookingServiceFacade for an example."
>
> No caso eu uso ViewModel em vez de DTO.
>
>
>
> --

> Voc� recebeu esta mensagem porque faz parte do grupo .Net Architects

> hospedado no Google Groups.
> Para postar envie uma mensagem para dotnetar...@googlegroups.com
> Para sair do grupo envie uma mensagem para

> mailto:dotnetarchitects%2Bunsu...@googlegroups.com
> Para mais op��es visite o grupo em
> http://groups.google.com/group/dotnetarchitects?hl=pt-br
>
> --
> Voc� recebeu esta mensagem porque faz parte do grupo .Net Architects

> hospedado no Google Groups.
> Para postar envie uma mensagem para dotnetar...@googlegroups.com
> Para sair do grupo envie uma mensagem para
> dotnetarchitec...@googlegroups.com

> Para mais op��es visite o grupo em
> http://groups.google.com/group/dotnetarchitects?hl=pt-br

[Fernando Mondo]

eu tambem acho que estou misturando serviço de dominio com aplicação pois pelo que eu andei lendo a camada de aplicação só iria iniciar a transação e dar o saveChanges ou rollback + gravar log.

e então eu teria um serviço de Dominio +- assim:

public void ServicoLiberacao(){

_provedorApi.CriarUsuario(usuario, senha);

_contrato.TornarAtivo();
_repositorioContrato.Add(_contrato);
_notificador.EnviarEmail(_cliente);

}

mas daí eu teria uma camada de aplicação pequena demais, e no livro do Evans ele ainda diz que notificar por email é uma responsabilidade da Aplicação.

talvez seja por isso que o igor e o edmilson usam o controller da camada de apresentação como camada de aplicação....

Em 15 de abril de 2012 02:55, Lemol Lutonda <lez...@fecrd.cujae.edu.cu> escreveu:

Não entendí bem a lógica (essa nomenclatura me confunde :( ), mas, pelo
que percebo, parte é Serviço de Aplicação e uma parte estaria em um
Serviço de Dominio. Mas como disse, não entendí a lógica...

Se voce está achando que é regra de dominio, então provavelmente tinha que
ser/estar um serviço de dominio.

Atenciosamente,

Leza Morais Lutonda, Lemol-C
http://lemolsoft.webs.com
http://github.com/lemol
@lemolsoft on twitter
>
> From: Fernando Mondo
> Sent: Sunday, April 15, 2012 1:30 AM

> To: dotnetar...@googlegroups.com
> Subject: Re: [dotnetarchitects] Re: DDD - Camada de Aplicação e injeção de
> dependência
>

> Voltei com mais indagações...
>
> confesso que não entendi sobre o que o igor e o edmilson afirmaram de

> viewmodel na camada de aplicação..
>

> mas enfim, a minha dúvida inicial eu resolvi com o uso de factory.
>
> Atualmente o que eu tenho classes da aplicação que se parecem com isso:

>
> public class LiberarContrato
> {
> public LiberarContrato(Cliente cliente,Contrato contrato, IRepositorio,
> ILog){...}
>
> public void Liberar(string usuario, string senha)
> {
>   try{
>    _unidadeTrabalho.IniciarTrasacao();
>    _provedorApi.CriarUsuario(usuario, senha);
>    _contrato.TornarAtivo();
>    _repositorioContrato.Add(_contrato);
>    _notificador.EnviarEmail(_cliente);
>    _unidadeTrabalho.Salvar();
>   }
>   catch(exception e)
>   {
>    _unidadeTrabalho.RollBack();
>    _log.Gravar(e);
>   }
> }
>
> }
>

> Fica a dúvida então: Deveria esta classe ser um serviço do Domínio, já que
> eu tenho uma regra de negocio aqui dentro (ex: toda liberação exige criar

> um usuario numa api externa, tornar o contrato ativo e entiar email ao
> cliente)?
>

> Outra: deveria Dominio (ou Aplicação) possuir a interface IProvedorApi já

> que elá é que usa (sabendo que eu vou implementá-la na infra)?

>
>
>
> Em 5 de abril de 2012 15:56, Igor <oro...@gmail.com> escreveu:
>

>   O MVC todo é parte da camada de Interface, ou User Interface.

>   E no outro eu quis dizer serviços da camada de aplicação. ;)
>
>   Imagina assim, eu tenho dois projetos um WPF e um MVC certo? Não posso

> assumir que o C do MVC será a camada de aplicação.
>   Logo MVC é só User Interface e o WPF tbm. E quem coordena é a
> Application.
>

>   Esse explicação está no site e é bem legal.

>
>   "The application services in the sample application are responsible for
> driving workflow and coordinating transaction management (by use of the
> declarative transaction management support in Spring). They also provide
> a high-level abstraction for clients to use when interacting with the
> domain. These services are typically designed to define or support
> specific use cases. See BookingService or HandlingEventService.
>
>   In some situations, e.g. when dealing with graphs of lazy-loaded domain
> objects or when passing services' return values over network boundaries,
> the services are wrapped in facades. The facades handle ORM session
> management issues and/or convert the domain objects to more portable
> Data Transfer Objects) that can be tailored to specific use cases. In
> that case, we consider the DTO-serializing facade part of the interfaces
> layer. See BookingServiceFacade for an example."
>
>   No caso eu uso ViewModel em vez de DTO.
>
>
>
>   --

>   Você recebeu esta mensagem porque faz parte do grupo .Net Architects

> hospedado no Google Groups.
>   Para postar envie uma mensagem para dotnetar...@googlegroups.com
>   Para sair do grupo envie uma mensagem para

> mailto:dotnetarchitects%2Bunsu...@googlegroups.com

>   Para mais opções visite o grupo em
> http://groups.google.com/group/dotnetarchitects?hl=pt-br
>
> --
> Você recebeu esta mensagem porque faz parte do grupo .Net Architects

> hospedado no Google Groups.
> Para postar envie uma mensagem para dotnetar...@googlegroups.com
> Para sair do grupo envie uma mensagem para
> dotnetarchitec...@googlegroups.com

> Para mais opções visite o grupo em
> http://groups.google.com/group/dotnetarchitects?hl=pt-br

Lemol-C
...não paro até chegar lá...

Participe en la XVI Convencion Cientifica de Ingenieria y Arquitectura del 26 al 30 de noviembre de 2012. La Habana, Cuba: http://ccia.cujae.edu.cu

Consulte la enciclopedia colaborativa cubana. http://www.ecured.cu

--
Você recebeu esta mensagem porque faz parte do grupo .Net Architects hospedado no Google Groups.

Para postar envie uma mensagem para dotnetar...@googlegroups.com
Para sair do grupo envie uma mensagem para dotnetarchitec...@googlegroups.com

Para mais opções visite o grupo em http://groups.google.com/group/dotnetarchitects?hl=pt-br

[Lemol Lutonda]

Repositorio em servi�o de dominio? talvez n�o seja necessario agora.
Notificar por email n�o � opera��o do dominio, verdade?

>
> From: Fernando Mondo
> Sent: Sunday, April 15, 2012 12:52 PM
> To: dotnetar...@googlegroups.com

> Subject: Re: [dotnetarchitects] Re: DDD - Camada de Aplica��o e inje��o de
> depend�ncia
>

> eu tambem acho que estou misturando servi�o de dominio com aplica��o pois
> pelo que eu andei lendo a camada de aplica��o s� iria iniciar a transa��o

> e dar o saveChanges ou rollback + gravar log.
>

> e ent�o eu teria um servi�o de Dominio +- assim:

>
> public void ServicoLiberacao(){
> _provedorApi.CriarUsuario(usuario, senha);
>
> _contrato.TornarAtivo();
> _repositorioContrato.Add(_contrato);
> _notificador.EnviarEmail(_cliente);
>
> }
>

> mas da� eu teria uma camada de aplica��o pequena demais, e no livro do
> Evans ele ainda diz que notificar por email � uma responsabilidade da
> Aplica��o.

>
> talvez seja por isso que o igor e o edmilson usam o controller da camada

> de apresenta��o como camada de aplica��o....

>
>
> Em 15 de abril de 2012 02:55, Lemol Lutonda <lez...@fecrd.cujae.edu.cu>
> escreveu:
>
>

> N�o entend� bem a l�gica (essa nomenclatura me confunde :( ), mas, pelo
> que percebo, parte � Servi�o de Aplica��o e uma parte estaria em um
> Servi�o de Dominio. Mas como disse, n�o entend� a l�gica...
>

> Se voce est� achando que � regra de dominio, ent�o provavelmente tinha
> que
> ser/estar um servi�o de dominio.

>
>
> Atenciosamente,
>
> Leza Morais Lutonda, Lemol-C
> http://lemolsoft.webs.com
> http://github.com/lemol
> @lemolsoft on twitter
> >
> > From: Fernando Mondo
> > Sent: Sunday, April 15, 2012 1:30 AM
>
> > To: dotnetar...@googlegroups.com

> > Subject: Re: [dotnetarchitects] Re: DDD - Camada de Aplica��o e
> inje��o de
> > depend�ncia
> >
>
> > Voltei com mais indaga��es...
> >
> > confesso que n�o entendi sobre o que o igor e o edmilson afirmaram de
> > viewmodel na camada de aplica��o..
> >

> > mas enfim, a minha d�vida inicial eu resolvi com o uso de factory.
> >
> > Atualmente o que eu tenho classes da aplica��o que se parecem com

> isso:
> >
> > public class LiberarContrato
> > {
> > public LiberarContrato(Cliente cliente,Contrato contrato,
> IRepositorio,
> > ILog){...}
> >
> > public void Liberar(string usuario, string senha)
> > {
> > try{
> > _unidadeTrabalho.IniciarTrasacao();
> > _provedorApi.CriarUsuario(usuario, senha);
> > _contrato.TornarAtivo();
> > _repositorioContrato.Add(_contrato);
> > _notificador.EnviarEmail(_cliente);
> > _unidadeTrabalho.Salvar();
> > }
> > catch(exception e)
> > {
> > _unidadeTrabalho.RollBack();
> > _log.Gravar(e);
> > }
> > }
> >
> > }
> >

> > Fica a d�vida ent�o: Deveria esta classe ser um servi�o do Dom�nio, j�

> que
> > eu tenho uma regra de negocio aqui dentro (ex: toda libera��o exige
> criar

> > um usuario numa api externa, tornar o contrato ativo e entiar email ao
> > cliente)?
> >

> > Outra: deveria Dominio (ou Aplica��o) possuir a interface IProvedorApi
> j�

> > que el� � que usa (sabendo que eu vou implement�-la na infra)?

> >
> >
> >
> > Em 5 de abril de 2012 15:56, Igor <oro...@gmail.com> escreveu:
> >

> > O MVC todo � parte da camada de Interface, ou User Interface.

> > E no outro eu quis dizer servi�os da camada de aplica��o. ;)
> >
> > Imagina assim, eu tenho dois projetos um WPF e um MVC certo? N�o
> posso

> > assumir que o C do MVC ser� a camada de aplica��o.
> > Logo MVC � s� User Interface e o WPF tbm. E quem coordena � a
> > Application.
> >

> > Esse explica��o est� no site e � bem legal.

> >
> > "The application services in the sample application are responsible
> for
> > driving workflow and coordinating transaction management (by use of
> the
> > declarative transaction management support in Spring). They also
> provide
> > a high-level abstraction for clients to use when interacting with the
> > domain. These services are typically designed to define or support
> > specific use cases. See BookingService or HandlingEventService.
> >
> > In some situations, e.g. when dealing with graphs of lazy-loaded
> domain
> > objects or when passing services' return values over network
> boundaries,
> > the services are wrapped in facades. The facades handle ORM session
> > management issues and/or convert the domain objects to more portable
> > Data Transfer Objects) that can be tailored to specific use cases. In
> > that case, we consider the DTO-serializing facade part of the
> interfaces
> > layer. See BookingServiceFacade for an example."
> >
> > No caso eu uso ViewModel em vez de DTO.
> >
> >
> >
> > --

> > Voc� recebeu esta mensagem porque faz parte do grupo .Net Architects

> > hospedado no Google Groups.
> > Para postar envie uma mensagem para
> dotnetar...@googlegroups.com
> > Para sair do grupo envie uma mensagem para
>

> > mailto:mailto:dotnetarchitects%252Buns...@googlegroups.com
>
> > Para mais op��es visite o grupo em
> > http://groups.google.com/group/dotnetarchitects?hl=pt-br
> >
> > --
> > Voc� recebeu esta mensagem porque faz parte do grupo .Net Architects

> > hospedado no Google Groups.
> > Para postar envie uma mensagem para dotnetar...@googlegroups.com
> > Para sair do grupo envie uma mensagem para
> > mailto:dotnetarchitects%2Bunsu...@googlegroups.com

> > Para mais op��es visite o grupo em
> > http://groups.google.com/group/dotnetarchitects?hl=pt-br
>
>
>
> Lemol-C

> ...não paro até chegar lá...
>

> Participe en la XVI Convencion Cientifica de Ingenieria y Arquitectura
> del 26 al 30 de noviembre de 2012. La Habana, Cuba:
> http://ccia.cujae.edu.cu
>
> Consulte la enciclopedia colaborativa cubana. http://www.ecured.cu
>
>
> --

> Voc� recebeu esta mensagem porque faz parte do grupo .Net Architects

> hospedado no Google Groups.
> Para postar envie uma mensagem para dotnetar...@googlegroups.com
> Para sair do grupo envie uma mensagem para
> mailto:dotnetarchitects%2Bunsu...@googlegroups.com

> Para mais op��es visite o grupo em
> http://groups.google.com/group/dotnetarchitects?hl=pt-br
>
> --
> Voc� recebeu esta mensagem porque faz parte do grupo .Net Architects

> hospedado no Google Groups.
> Para postar envie uma mensagem para dotnetar...@googlegroups.com
> Para sair do grupo envie uma mensagem para
> dotnetarchitec...@googlegroups.com

> Para mais op��es visite o grupo em
> http://groups.google.com/group/dotnetarchitects?hl=pt-br

Lemol-C

...não paro até chegar lá...

Participe en la XVI Convencion Cientifica de Ingenieria y Arquitectura del 26 al 30 de noviembre de 2012. La Habana, Cuba: http://ccia.cujae.edu.cu

[Rodrigo Silva de Andrade]

Eu imagino que se a "regra" seja enviar email, ela possa ficar no dominio, mas o mecanismo que de fato envia o email, seja da infra. Depende do contexto.

On Sun, Apr 15, 2012 at 3:33 PM, Lemol Lutonda <lez...@fecrd.cujae.edu.cu> wrote:

Repositorio em serviço de dominio? talvez não seja necessario agora.
Notificar por email não é operação do dominio, verdade?

>
> From: Fernando Mondo
> Sent: Sunday, April 15, 2012 12:52 PM

> To: dotnetar...@googlegroups.com
> Subject: Re: [dotnetarchitects] Re: DDD - Camada de Aplicação e injeção de
> dependência
>

> eu tambem acho que estou misturando serviço de dominio com aplicação pois

> pelo que eu andei lendo a camada de aplicação só iria iniciar a transação

> e dar o saveChanges ou rollback + gravar log.
>

> e então eu teria um serviço de Dominio +- assim:

>
> public void ServicoLiberacao(){
> _provedorApi.CriarUsuario(usuario, senha);
>
> _contrato.TornarAtivo();
> _repositorioContrato.Add(_contrato);
> _notificador.EnviarEmail(_cliente);
>
> }
>

> mas daí eu teria uma camada de aplicação pequena demais, e no livro do

> Evans ele ainda diz que notificar por email é uma responsabilidade da
> Aplicação.
>

> talvez seja por isso que o igor e o edmilson usam o controller da camada

> de apresentação como camada de aplicação....
>
>

> Em 15 de abril de 2012 02:55, Lemol Lutonda <lez...@fecrd.cujae.edu.cu>
> escreveu:
>
>

>   Não entendí bem a lógica (essa nomenclatura me confunde :( ), mas, pelo
>   que percebo, parte é Serviço de Aplicação e uma parte estaria em um
>   Serviço de Dominio. Mas como disse, não entendí a lógica...
>

>   Se voce está achando que é regra de dominio, então provavelmente tinha
> que
>   ser/estar um serviço de dominio.

>
>
>   Atenciosamente,
>
>   Leza Morais Lutonda, Lemol-C
>   http://lemolsoft.webs.com
>   http://github.com/lemol
>   @lemolsoft on twitter
>   >
>   > From: Fernando Mondo
>   > Sent: Sunday, April 15, 2012 1:30 AM
>
>   > To: dotnetar...@googlegroups.com

>   > Subject: Re: [dotnetarchitects] Re: DDD - Camada de Aplicação e
> injeção de
>   > dependência
>   >
>
>   > Voltei com mais indagações...
>   >
>   > confesso que não entendi sobre o que o igor e o edmilson afirmaram de
>   > viewmodel na camada de aplicação..
>   >

>   > mas enfim, a minha dúvida inicial eu resolvi com o uso de factory.
>   >
>   > Atualmente o que eu tenho classes da aplicação que se parecem com

> isso:
>   >
>   > public class LiberarContrato
>   > {
>   > public LiberarContrato(Cliente cliente,Contrato contrato,
> IRepositorio,
>   > ILog){...}
>   >
>   > public void Liberar(string usuario, string senha)
>   > {
>   >   try{
>   >    _unidadeTrabalho.IniciarTrasacao();
>   >    _provedorApi.CriarUsuario(usuario, senha);
>   >    _contrato.TornarAtivo();
>   >    _repositorioContrato.Add(_contrato);
>   >    _notificador.EnviarEmail(_cliente);
>   >    _unidadeTrabalho.Salvar();
>   >   }
>   >   catch(exception e)
>   >   {
>   >    _unidadeTrabalho.RollBack();
>   >    _log.Gravar(e);
>   >   }
>   > }
>   >
>   > }
>   >

>   > Fica a dúvida então: Deveria esta classe ser um serviço do Domínio, já
> que
>   > eu tenho uma regra de negocio aqui dentro (ex: toda liberação exige

> criar
>   > um usuario numa api externa, tornar o contrato ativo e entiar email ao
>   > cliente)?
>   >

>   > Outra: deveria Dominio (ou Aplicação) possuir a interface IProvedorApi
> já

>   > que elá é que usa (sabendo que eu vou implementá-la na infra)?

>   >
>   >
>   >
>   > Em 5 de abril de 2012 15:56, Igor <oro...@gmail.com> escreveu:
>   >

>   >   O MVC todo é parte da camada de Interface, ou User Interface.

>   >   E no outro eu quis dizer serviços da camada de aplicação. ;)
>   >
>   >   Imagina assim, eu tenho dois projetos um WPF e um MVC certo? Não
> posso

>   > assumir que o C do MVC será a camada de aplicação.
>   >   Logo MVC é só User Interface e o WPF tbm. E quem coordena é a
>   > Application.
>   >

>   >   Esse explicação está no site e é bem legal.

>   >
>   >   "The application services in the sample application are responsible
> for
>   > driving workflow and coordinating transaction management (by use of
> the
>   > declarative transaction management support in Spring). They also
> provide
>   > a high-level abstraction for clients to use when interacting with the
>   > domain. These services are typically designed to define or support
>   > specific use cases. See BookingService or HandlingEventService.
>   >
>   >   In some situations, e.g. when dealing with graphs of lazy-loaded
> domain
>   > objects or when passing services' return values over network
> boundaries,
>   > the services are wrapped in facades. The facades handle ORM session
>   > management issues and/or convert the domain objects to more portable
>   > Data Transfer Objects) that can be tailored to specific use cases. In
>   > that case, we consider the DTO-serializing facade part of the
> interfaces
>   > layer. See BookingServiceFacade for an example."
>   >
>   >   No caso eu uso ViewModel em vez de DTO.
>   >
>   >
>   >
>   >   --

>   >   Você recebeu esta mensagem porque faz parte do grupo .Net Architects

>   > hospedado no Google Groups.
>   >   Para postar envie uma mensagem para
> dotnetar...@googlegroups.com
>   >   Para sair do grupo envie uma mensagem para
>

>   > mailto:mailto:dotnetarchitects%252Buns...@googlegroups.com

>
>   >   Para mais opções visite o grupo em
>   > http://groups.google.com/group/dotnetarchitects?hl=pt-br
>   >
>   > --
>   > Você recebeu esta mensagem porque faz parte do grupo .Net Architects

>   > hospedado no Google Groups.
>   > Para postar envie uma mensagem para dotnetar...@googlegroups.com
>   > Para sair do grupo envie uma mensagem para
>   > mailto:dotnetarchitects%2Bunsu...@googlegroups.com

>   > Para mais opções visite o grupo em
>   > http://groups.google.com/group/dotnetarchitects?hl=pt-br
>
>
>

>   Lemol-C

>   ...não paro até chegar lá...
>

>   Participe en la XVI Convencion Cientifica de Ingenieria y Arquitectura
> del 26 al 30 de noviembre de 2012. La Habana, Cuba:
> http://ccia.cujae.edu.cu
>
>   Consulte la enciclopedia colaborativa cubana. http://www.ecured.cu
>
>
>   --

>   Você recebeu esta mensagem porque faz parte do grupo .Net Architects

> hospedado no Google Groups.
>   Para postar envie uma mensagem para dotnetar...@googlegroups.com
>   Para sair do grupo envie uma mensagem para
> mailto:dotnetarchitects%2Bunsu...@googlegroups.com

>   Para mais opções visite o grupo em
> http://groups.google.com/group/dotnetarchitects?hl=pt-br
>
> --
> Você recebeu esta mensagem porque faz parte do grupo .Net Architects

> hospedado no Google Groups.
> Para postar envie uma mensagem para dotnetar...@googlegroups.com
> Para sair do grupo envie uma mensagem para
> dotnetarchitec...@googlegroups.com

> Para mais opções visite o grupo em
> http://groups.google.com/group/dotnetarchitects?hl=pt-br


Lemol-C

...não paro até chegar lá...

Participe en la XVI Convencion Cientifica de Ingenieria y Arquitectura del 26 al 30 de noviembre de 2012. La Habana, Cuba: http://ccia.cujae.edu.cu

Consulte la enciclopedia colaborativa cubana. http://www.ecured.cu

--

Você recebeu esta mensagem porque faz parte do grupo .Net Architects hospedado no Google Groups.

Para postar envie uma mensagem para dotnetar...@googlegroups.com
Para sair do grupo envie uma mensagem para dotnetarchitec...@googlegroups.com

Para mais opções visite o grupo em http://groups.google.com/group/dotnetarchitects?hl=pt-br

[Fernando Mondo]

Rodrigo, a implementação da classe que envia email certamente está na infra, mas eu ainda não sei onde colocar a interface.

Lemol, eu achava que ficava no Domínio, mas segundo o livro do Evans (é, denovo...) ele diz que é na aplicação...

[Anderson Dantas Correia]

Fernando,

Esse seu exemplo está com cara de Serviço de Aplicação. O seu serviço de domínio deve ser responsável por controlar apenas regras do negócio da sua aplicação, as quais estão não fazem sentido lógico dentro de uma entidade.

Por exemplo, suponha que tornar um contrato ativo no entendimento do negócio não fizesse sentido dentro da própria entidade Contrato, então seu Serviço de Aplicação seria algo:

AppService

{

  void AtivarContrato(Guid contratoId, Guid clienteId)

  {

      var cliente = Repositorio.Get(clienteId); //supondo que use esta abordagem

      var contrato = Repositorio.Get(contratoId); //suposição novamente

      var svc = new FluxoContratoDomainService();

      svc.Ativar(contrato);

      Repositorio.Add(contrato);

      Notificador.EnviarEmailAtivacao(contrato);

  }

}

FluxoDomainService

{

  void Ativar(Contrato c)

  {

      if (!ContratoStatusValido(c))

           throw new ApplicationException("Tá errado!");

      c.Status = ContratoStaus.Ativo;

  }

}

Claro que é um código um tanto simplista, mas espero que tenha ilustrado o conceito.

Atenciosamente,

Anderson Correia

Cel.: 19 8813-1039

Skype: correianet

MSN: corre...@hotmail.com

Linked-In: http://www.linkedin.com/in/andersoncorreia

[Fernando Mondo]

Valeu Anderson, como vc pode ver esta bem de acordo com o meu primeiro exemplo, onde uso os repositorios e a notificação por email na camada de aplicação, a unica diferença é que eu já recebo da interface o contrato e o cliente.

[Alessandro de Souza]

Apenas uma opinião.

Considere usar DOMAIN EVENTS.

 

http://blog.lambda3.com.br/2009/11/domain-events/

 

Você pode implementar os serviços na aplicação ou onde for.. e usar DI para resolver tudo.

Fica bem legal.

 

Att,

Alessandro

Em 17 de abril de 2012 09:23, Anderson Dantas Correia <info.c...@gmail.com> escreveu:

[Allan Clempe]

Interessante essa idéia de domain events, só me restou uma duvida. Quem garante a ordem em que os métodos serão resolvidos? 

Correria o risco de enviar o e-mail agradecendo ao cliente antes de realmente "aceitar" todas as regras de negócio para tal satisfação?

[Fernando Mondo]

eu já conhecia, mas tenho receio de usar porque não fica muito explicito o fluxo das rotinas da aplicação...

[Gerson Dias]

Allan,

Mas aí é só questão de organizar os eventos direito, não é.... pois vc pode mandar o e-mail como resultado do evento "ClienteSatisfezTodasAsRegrasDeNegocio" e não necessariamente do evento ClienteFoiCadastrado.

Agora quanto não ficar explicito o fluxo das rotinas da aplicação acho que é verdade sim, apesar de nunca ter visto isso em um projeto grande e "de verdade", vc vai ter que procurar bastante pra saber todos que assinam o evento.... mas com o nosso grande amigo R# não deve doer tanto não!

2012/4/17 Fernando Mondo <fernand...@gmail.com>

[Alessandro de Souza]

Não querido.

Ai sua camada de 'aplicação' que orquestra suas regras de negócio (ententa... orquestra e não gera regras de negócios.. isto é responsabilidade do domain... nossa se eu não falo heim...) só dispararia o evento após todas as regras serem satisfeitas/chamadas....

Não há confusão alguma.

 

Att,

Alessandro

Em 17 de abril de 2012 12:02, Allan Clempe <allan....@gmail.com> escreveu:

[Alessandro de Souza]

Ah e outro detalhe também... Cuidado onde os SERVIÇOS são implementados...Nessa confusão toda de dominio, aplicação infra etc... é fácil confundir serviços de domínio com serviços de aplicação e de infra...

 

http://lostechies.com/jimmybogard/2008/08/21/services-in-domain-driven-design/

 

Att,

Alessandro

Em 17 de abril de 2012 12:02, Allan Clempe <allan....@gmail.com> escreveu:

[Igor]

https://groups.google.com/forum/?hl=pt&fromgroups#!searchin/dotnetarchitects/unity$20entity$20framework/dotnetarchitects/BjmFZVHoJ0o/gudXZ5izLsoJ

Estava procurando algum tópico que tivesse o assunto que eu estou "encucado" e achei esse aqui que deve servir de exemplo para você.
Leia o comentario do Giovanni.

[Fernando Mondo]

Alessandro, tudo muito lindo, mas ess artigo diz que a interface de enviarEmail estaria na infra, o que é estranho pois eu não posso acessar a infra, e ainda não deixa claro que iria usar esta interface se é a plicação ou dominio.

Igor, o que o Giovanni disse é mais ou menos o que eu fiz: a aplicação coordena entidades do Dominio, usa os repositorios, da o SaveChanges na unitOfWork, ou grava um log de erro. mas o  _provedorApi.CriarUsuario(usuario, senha); e _notificador.EnviarEmail(_cliente); são chamados na aplicação ou dominio?

Eu sei que os dois vão ser implementados na Infra pois dependem de uma tecnologia específica ( Soap e Smtp respectivamente), mas onde são usados e também oude devo deixar suas interfaces.

Eu estou pensando em interfaces no Dominio e uso na Aplicação, mas fica me parecendo que tenho regras de negócio na aplicação...

[Alessandro de Souza]

Não é confuso.

Se o serviço é de infra deixa a interface dele na infra, se é de aplicação deixa a interface dele na aplicação.

Conforme seu tópico, quem junta tudo isso e injeta no lugar onde é necessário é o DI....

 

Exemplo bobo:

 

meuprojeto.infra.interfaces

meuprojeto.infra.implementações

 

As demais camadas enchergam apenas o meuprojeto.infra.interfaces...

 

Lembre-se da representação gráfica do DDD - a interface e a aplicação podem enxergar a infra, o contrário não. Só que pra ficar desacoplado a aplicação deve enxergar apenas as interfaces da infra.

Ai fica legal.....

 

Att,

Alessandro

[Igor]

Pelo que eu vi enviar email é uma notificação e não uma regra de negocio, o que acontece a camada de aplicação coordena as suas regras de negocio, pois exemplo:

{

var Usuario = new Usuario();

Usuario.AtivarUsuario();
Usuario.EfetuarPublicacao();
Usuario.AtualizarStatus("aprovado");

Notificacao.EnviarEmailDeAprovacao(Usuario);

}

Note que esses metodos são da entidade, mas esse codigo fica na camada de aplicação.
Minhas regras de negocios ficam no dominio mas a coordenação (ordem...) fica no serviço da camada de Aplicação.

*Codigo para exemplificar.

[Fernando Mondo]

é que eu optei pela onion architecture onde Aplicação não conhece Infra ( e sim o contrário), o que pra mim faz sentido já que a infra tem a unica responsabilidade de implementar as interfaces do domino e aplicação (que neste caso ainda não sei em qual das duas fica o INotificador)

[Fernando Mondo]

Se for assim eu estou fazendo certinho.. mas a interface do Notificador e da Api ficariam no Domínio ou na aplicação?

[Alessandro de Souza]

Não sei o seu cenário completo, mas pelo que percebi creio que a notificação seja um serviço de responsabilidade da apalicação e não de regra de negócios... Então meu voto vai para: dixar a interface na camada de aplicação.

 

Att,

Alessandro

[Marcus Alexandre Silva]

Fernando, 

Pelo que percebi você esta com dificuldades de separar sua aplicação, esta com dificuldades em saber o que é a infra e o que é o domínio, deixa eu tentar te ajudar, imaginando que cada camada fosse um assembly:

1: SuaApp.Core:  (Ou business, ou o nome que desejar....)

Não depende de ninguém, preferencialmente do minimo que o .net precisa para rodar. Mas aqui você tem TODAS as interfaces de repositórios e services de infra, como a IEnviarEmail.

2: SuaApp.Infraestrutura.Repositorios: (Ou persistência ou o nome que desejar....)

Conhece "SuaApp.Core", conhece sua ORM, ou ADO ou o que você quiser usar para implementar os IRepositrios da vida...

3: SuaApp.Infraestrutura.Email: (ou o nome que desejar....)

Conhece "SuaApp.Core", e implementa o que precisar para você mandar seus emails...

Ps: Separei a 2 e a 3 pra tentar ser didático, pouco importava se estivesse em um mesmo assembly "SuaApp.Infraestrutura", DEPENDE, da sua aplicação, o que você espera que mude um dia, sei la....

4: SuaApp.UserInterface (ou web ou windows ou mobile ou o nome que desejar...)

Conhece   "SuaApp.Core", e, preferencialmente, conhece "SuaApp.Infraestrutura" com técnicas de IoC/DI/qualquer coisa faça o mapeamento proxy/interface (você ate referencia no projeto a Infra, mas não consume nada direto dela), mas você sempre vai fazer as chamadas a partir dos Serviços/Fabricas do Core...

É claro que estou sendo muito simplista, mas a intenção é só clarear "quem conhece quem"...

Marcus Alexandre

[Alessandro de Souza]

Marcus.

Se você me permite, eu discordaria de você em apenas um detalhe.

Onde ficam as interfaces. Acho que as interfaces que não tem haver com o dominio (ou core como vc chama) não devem ficar no core e sim no assembly (usando sua analogia muito bem colocada) da própria camada.

Porque penso assim. Qual o objetivo das interfaces? Ser a porta de entrada e o contrato para os serviços (ou outro nome qualquer) que são implementados 'por baixo' delas. Seriam como a portas de entrada: onde fica  porta do quarto? No quarto...  rsrsrs... Entende o que quero dizer?

 

E o DI conhece todas as camadas e as resolve.

 

No caso dos repositórios eu concordo em ficar no core/dominio porque tem haver diretamente com ele. As interfaces de serviços de DOMINIO também da mesma forma, agora as demais de infra ai acho que as interfaces não devem ser definidas nesse assembly.

 

Att,

Alessandro

[Fernando Mondo]

marcus, esta estrutura que você definil muito bem eu já esta estou familizrizado e faço exatamente assim. O meu problema é justamente com a camada que você não comentou, a camada de Aplicação.

por exemplo, eu sei que a camada de aplicão possui uma unitOfWork e que grava logs de erros, isso não tem nada a var com o domínio e eu deixar as interfaces IUnitOfWork e Ilog na camada de aplicação.

Como eu dependo de uma tecnologia expecífica para implementá-las a camada de Infra faz isso, Usando o EntityFramework e o LogForNet por exemplo...

Agora INotificador e IProvedorApi estão relacionadas ao meu negócio porque eu tenho a regra que "para eu liberar um contráto é preciso criar um usuario por uma api externa, tornar o contrato ativo e enviar um email para o cliente"

Eu estou atualmente com estas interfaces na aplicação pois é onde eu as uso. porem me indaga o fato de que se isto é uma regra do meu negócio, não deveria estar no Domínio?

se por acaso o Domínio não as usar e sim a aplicação,  pelo menos suas interfaces não deveriam estar no Domínio?

[Marcus Alexandre Silva]

Alessandro,

Eu gosto de separar meu Core nos seguintes namespaces dentro do meu unico assembly:

Dominio/ Repositorios / Fabricas / Servicos / Util

Quanto as interfaces, o que fica no *namespace* domínio acaba não conhecendo, mas os services acabam conhecendo tudo, acredito que se faz parte da minha regra de negocio "Enviar email apos cadastrar Usuário", IEnvioEmail e ICadastroUsuario (ou repositório de usuários) acaba sendo uma dependência do serviço SegurancaSistema...

class SegurancaSistema

    ctor:  SegurancaSistema ( IEnvioEmail envioEmail, ICadastroUsuario cadastroUsuario);

    void CadastrarUsuario(Usuario usuario) {

         ExecutarTransacao( () => 

           {

              usuario.ValidarParaNovoCadastro();

              usuario.CriarPerfisDeSegurancaBasico();

              cadastroUsuario.Persistir(usuario);

              envioEmail.Enviar(cadastroUsuario.Email, this.ObterTextoCadastro(usuario);

           }

         , falha => 

           {

               (...)    

           });

   }

Acredito que os Serviços do Domínio *sempre* conheçam o contrato de implementação da infraestrutura, pois o contrato faz parte da regra de negócios, sua implementação de como isto é feito é que pouco importa para ele... 

Esta estrutura inclusive me auxilia muito nos testes dos meus Serviços. Sei exatamente que cada interface desta é um mock que precisa ser criado...

ps: não existe este projeto, só exemplificando!

Marcus Alexandre

[Alessandro de Souza]

Marcus.. nesse caso eu concordo plenamente com você.

Se enviar e-mail para o usuário após cadastro é uma regra de negócio ai sim a interface IEnviarEmailParaCliente deve ser definida no domínio mesmo.

Gostei também da sua separação entro do CORE entre dominio / serviços etc... apesar de estarem no mesmo assembly estão separados por namespace. Legal...

Obrigado por suas considerações.

Att,

Alessandro

[Igor]

Não consigo enchegar Email como uma regra de negocio e sim como uma notificação.
Se for assim todos os emails é regra de negocio e não o são.

[Alessandro de Souza]

Não Igor, não concordo.

Estamos falando de DDD correto. Se na entrevista com o especialista do negócio ele citar o envio de e-mail como sendo item obrigatório após uma ação do sistema isso passa a fazer parta da  UBIQUITOUS LANGUAGE e por consequência passa a fazer parte do domínio. A implementação dela, de fato não será feita no domínio e sim na infra, porém a sua interface deverá ser definida no domínio mesmo. Claro que você pode implementar DOMAIN EVENTS e tratar isso como um evento, porém não deixará de fazer parte do domínio.

Se falei besteira, me desculpem.

Att,

Alessandro

Em 18 de abril de 2012 16:37, Igor <oro...@gmail.com> escreveu:

Não consigo enchegar Email como uma regra de negocio e sim como uma notificação.
Se for assim todos os emails é regra de negocio e não o são.

[Marcus Alexandre Silva]

Fernando, 

Você tem uma camada de aplicação, não tinha percebido isto... 

Eu trato a camada de aplicação exatamente igual trato uma UI quanto a questão de dependências e assemblys:

"Conhece   "SuaApp.Core", e, preferencialmente, conhece "SuaApp.Infraestrutura" com técnicas de IoC/DI/qualquer coisa faça o mapeamento proxy/interface (você ate referencia no projeto a Infra, mas não consume nada direto dela), mas você sempre vai fazer as chamadas a partir dos Serviços/Fabricas do Core.. "

Quanto o  UnitOfWork, sinceramente eu gosto dela na camada de domínio como uma interface idependente, tipo:

(tudo que o domínio precisa conhecer)

ITransacao {

     Iniciar();

     Cancelar();

     Submeter();

}

Na minha *assembly* de repositórios, ai sim eu teria conhecimento dela, no seu caso com entityframework seria:

public class ExemploContext : ObjectContext, ITransacao 

{

}

A grande questão ai é como tratar esta Unidade de trabalho nos repositórios, podemos ter no *abstract* RepositorioBase os seguintes construtores:

ExemploContext _transacao;

RepositorioBase() : this(new ExemploContext() ) {}

RepositorioBase( ITransacao  transacao) 

{

  _transacao = transacao as ExemploContext;

}

Desta maneira, você pode criar uma serie de repositórios presos a uma só transação, do jeito que sua regra de negócios pedir, a implementação do metodo seria algo parecido como:

public void Persistir(Usuario usuario) {

    _transacao.Usuarios.AddObject(usuario) ;

}

Assim, o exemplo que passei para o Alessandro (numa classe abstrata de serviço dentro do próprio domínio) ficaria assim:

void ExecutarTransacao(Action metodo, Action<Exception> excessão) {

    try 

    {

       _transacao.Iniciar();

       metodo();

       _transacao.Submeter();

    }

    catch (Exception exception)

    {

       _transacao. Cancelar();

       excessão(exception);

    }

}

Quanto ao logs, sinceramente eu gosto da ideia de AOP com PostSharp, mas você não conseguiria deixar seu domínio independente dele, embora, neste caso, eu ache muito purismo não utiliza-lo... Se você quiser seguir a risca a infra de IoC, seu ILog nada mais é que outro repositório (que persiste) em que TODOS os serviços serão dependentes... Particularmente, não gosto.

Peço desculpas se os exemplos não estão didáticos o suficiente, já tem alguns meses que não tenho contato efetivo com DDD e to tentando responder nos intervalos do trabalho...

Atenciosamente,

[Marcus Alexandre Silva]

"Agora INotificador e IProvedorApi estão relacionadas ao meu negócio porque eu tenho a regra que "para eu liberar um contráto é preciso criar um usuario por uma api externa, tornar o contrato ativo e enviar um email para o cliente" "

Eu não conheço bem o suficiente o seu projeto, mas uma coisa que me parece nesta colocação é que, provavelmente voce pense que repositórios tem a ver com banco de dados, o seu repositório ICadastroUsuario (ou ProvedorApi como você chamou - faz sentido para seu negocio este nome?) pode muito bem ser implementado em uma camada (assembly) que tenha as referencias para as api'a esternas que voce quer (sem orm ou  ado), assim métodos como ObterUsuarioPeloCpf() ou PersistirUsuario() também fazer a referencia a esta API. Mas mesmo assim continuará sendo uma interface de repositórios para seu negocio, inclusive passível de mock em seus testes unitarios... (testando fronteiras...)

Não sei tudo que sua  IProvedorApi faz, mas ela deve estar fazendo muita coisa que esta tornando invisível os papeis dos serviços e repositórios da infra para DDD, não? 

Difícil ajudar sem conhecer o projeto.... :)

Marcus Alexandre

Em 18 de abril de 2012 13:17, Fernando Mondo <fernand...@gmail.com> escreveu:

[Marcus Alexandre Silva]

Serio. 

Se eu não começar a reler os e-mails que mando antes de apertar 'enviar' vou passar cada vergonha por aqui.... Desconsiderem o português.

[Lemol Lutonda]

Aten��o que o processo que consiste em:

> Usuario.AtivarUsuario();
> Usuario.EfetuarPublicacao();
> Usuario.AtualizarStatus("aprovado");

pode ser uma regra de negocio.

>
> From: Igor
> Sent: Wednesday, April 18, 2012 12:09 PM
> To: dotnetar...@googlegroups.com
> Subject: [dotnetarchitects] Re: DDD - Camada de Aplica��o e inje��o de
> depend�ncia
>
> Pelo que eu vi enviar email � uma notifica��o e n�o uma regra de negocio,
> o que acontece a camada de aplica��o coordena as suas regras de negocio,

> pois exemplo:
>
>
> {
>
> var Usuario = new Usuario();
>
> Usuario.AtivarUsuario();
> Usuario.EfetuarPublicacao();
> Usuario.AtualizarStatus("aprovado");
>
> Notificacao.EnviarEmailDeAprovacao(Usuario);
>
> }
>

> Note que esses metodos s�o da entidade, mas esse codigo fica na camada de
> aplica��o.
> Minhas regras de negocios ficam no dominio mas a coordena��o (ordem...)
> fica no servi�o da camada de Aplica��o.
>
> *Codigo para exemplificar.
>
> --
> Voc� recebeu esta mensagem porque faz parte do grupo .Net Architects

> hospedado no Google Groups.
> Para postar envie uma mensagem para dotnetar...@googlegroups.com
> Para sair do grupo envie uma mensagem para
> dotnetarchitec...@googlegroups.com

> Para mais op��es visite o grupo em
> http://groups.google.com/group/dotnetarchitects?hl=pt-br

Lemol-C
...não paro até chegar lá...

[Fernando Mondo]

o exemplo de provedorApi é só pra ilustrar que eu tenho que acessar algo externo, não se trata de repositorio e sim de Algo indefinido da infra...

Tipo, tem um exemplo + ou - real aqui do trabalho de um provedor de boletos do bradesco, onde para eu criar um boleto a um cliente eu devo:

Ir ao bradesco por uma Api e retornar o numero do boleto
criar um boleto com os dados retornados e gravar no meu banco de dados, depois devolver para a interface que irá mostrar ao cliente (o usuario do sistema)

então pensando que este processo esta na camada de aplicação eu teria algo como:

public class BoletoAplicationService{

public Boleto Criar(Fatura fatura){
try{
var boleto = _provedorBradesco.CriarBoleto(fatura.Id)//a interface do provedorBoleto foi implementada na infra, já que usa O WebService e tal
_repositorio.Add(boleto)
_unitOfWork.Commit();
return boleto;
}
catch(exception e){
_Log.Gravar(e);
UnitOfWork.RollBack()
return null;
}
}

agora volto a me repitir, tenho que emcapsular isto em um serviço de Domínio ou deixo esta regra na aplicação mesmo e a interface do prodedorBoleto deixo na Aplicação ou no Domínio?

eu sei que no final não vai fazer muita diferença, são apenas detalhes, mas eu acho válido filosofar a respeito.

Em 18 de abril de 2012 19:27, Lemol Lutonda <lez...@fecrd.cujae.edu.cu> escreveu:

Atenção que o processo que consiste em:

> Usuario.AtivarUsuario();
> Usuario.EfetuarPublicacao();
> Usuario.AtualizarStatus("aprovado");

pode ser uma regra de negocio.

>
> From: Igor
> Sent: Wednesday, April 18, 2012 12:09 PM
> To: dotnetar...@googlegroups.com

> Subject: [dotnetarchitects] Re: DDD - Camada de Aplicação e injeção de
> dependência
>

> Pelo que eu vi enviar email é uma notificação e não uma regra de negocio,
> o que acontece a camada de aplicação coordena as suas regras de negocio,

> pois exemplo:
>
>
> {
>
> var Usuario = new Usuario();
>
> Usuario.AtivarUsuario();
> Usuario.EfetuarPublicacao();
> Usuario.AtualizarStatus("aprovado");
>
> Notificacao.EnviarEmailDeAprovacao(Usuario);
>
> }
>

> Note que esses metodos são da entidade, mas esse codigo fica na camada de

> aplicação.
> Minhas regras de negocios ficam no dominio mas a coordenação (ordem...)
> fica no serviço da camada de Aplicação.
>
> *Codigo para exemplificar.
>

> --
> Você recebeu esta mensagem porque faz parte do grupo .Net Architects

> hospedado no Google Groups.
> Para postar envie uma mensagem para dotnetar...@googlegroups.com
> Para sair do grupo envie uma mensagem para
> dotnetarchitec...@googlegroups.com

> Para mais opções visite o grupo em
> http://groups.google.com/group/dotnetarchitects?hl=pt-br

Lemol-C

...não paro até chegar lá...

Participe en la XVI Convencion Cientifica de Ingenieria y Arquitectura del 26 al 30 de noviembre de 2012. La Habana, Cuba: http://ccia.cujae.edu.cu

Consulte la enciclopedia colaborativa cubana. http://www.ecured.cu

--
Você recebeu esta mensagem porque faz parte do grupo .Net Architects hospedado no Google Groups.

Para postar envie uma mensagem para dotnetar...@googlegroups.com
Para sair do grupo envie uma mensagem para dotnetarchitec...@googlegroups.com

Para mais opções visite o grupo em http://groups.google.com/group/dotnetarchitects?hl=pt-br

[Igor]

@Lemol-C
O que eu tenho são três regras de negocio distintas, e a sua execusão é ordenada, quem é responsavel por ordenar a sua execução é a camada da aplicação (serviço de aplicação).

@Fernando

Eu criaria um serviço na camada de aplicação para mim faria mais sentido, até por que apesar de ter as interfaces do repositorio eu não os uso na camada de dominio e sim e somente sim na camada de aplicação.
Há quem use o repositorio no serviço do dominio, mas eu sempre uso nos serviços da aplicação.