| Autor |
Mensagem |
|
|
Lezinho wrote:... quem armazena informações no DDD são os Repositories. Eles não armazenam ou coletam identificadores, eles trabalham com Entities.
Como estamos falando de camada de visão, abstraia repositorios por um momento...
Na opcao 1 do exemplo que usei o cliente do service da aplicacao passa apenas um identificador do entity a ser criado e persistido (o nome do usuario).
|
 |
|
|
TeiTei wrote:_rafael eu sou de são paulo e falo que o que vc esta falando e grotesco e prova que vc nao tem um pingo de visao, sabia que um doa miores polos de informatica do brasil estao localizados no nordeste e norte?
Voce deve ser um preconceituoso, e um daqueles programadores que amam chupinhar codigo mas nao desenvolve uma linha por conta propria.
Putz, o cara é escroto... Tem que banir esse merda do forum pra sempre!
|
|
|
|
rodrigoy wrote:
cmoscoso wrote: A minha opinião é a seguinte:
Não diria que é incorreto do ponto de vista DDD mas acredito que o melhor é, sempre que for possível, manter os metodos do Service da aplicação com parametros de tipos básicos.
O que ganhamos com isso?
Se você tem uma facade na aplicacao vai ganhar uma interface simples do ponto de vista do cliente
1) long criaUsuario(String name);
2) long criaUsuario(Usuario usuario);
Pra quem está programando o cliente qual das duas opcoes lhe parece melhor? Afinal se aplicacao orquestra deixemos ela orquestrar!
Repito, não é errado do ponto de vista das regras de negocio, o que esta vazando na opcao 2 provavelmente é regra de aplicacao. Mas daí pra vazar regras de negócio é um pulo.
Quanto a quantidade de parametros necessarios para persistir um entity...
Sera mesmo que todos esses parametros sao necessários para apenas persistir o entity, ou seja, cria-lo no seu sistema? (geralmente vc precisa apenas de identificadores pra isso)
Deixando o CRUD de lado... Ou são todos esses parametros necessários para a execucao de alguma regra de negocio que tal entity participa?
Neste ultimo caso, modele o objeto de dominio em questao considerando a possibilidade dele existir no sistema mas nao estar pronto para alguma atividade de negocio relacionada. Tipo um usuario existe no sistema mas não pode fazer nada ainda pq nao preencheu um cadastro detalhado.
No caso de uma atualizacao nao vejo problemas em passar o proprio objeto de dominio a ser atualizado. Neste caso ele já é conhecido pelo usuarioda interface.
|
|
|
|
BiraBoy wrote:Gente, pensando em DDD, é correto instanciar uma classe de domínio na camada de visão?
Pensei nisso porque pode haver, pensando em CRUD, uma Entity que tenha muitos atributos e seria melhor instanciar e popular na visão e então passar ao Service que orquestra a persistência. Criar um método com dezenas de parâmetros não parece adequado.
E da mesma forma se for uma atualização, popular o objeto com os atributos de atualização na visão.
Se isso for incorreto em Domain-Driven Design, qual seria a melhor saída?
Fala BiraBoy,
Essa é uma questão que surgiu recentemente no meu trabalho. A minha opinião é a seguinte:
Não diria que é incorreto do ponto de vista DDD mas acredito que o melhor é, sempre que for possível, manter os metodos do Service da aplicação com parametros de tipos básicos. Se você tem um entity com muitos atributos talvez esteja na hora de quenrar esse objeto de domínio em outros formando um agregado. Isso é correto do ponto de vista DDD!
Outra coisa, cuidado ao pensar em CRUD e DDD ao mesmo tempo!
Abs,
|
|
|
|
BiraBoy wrote:Cara, é que pelo que tenho lido (nas lidas saltadas do livro do Evans e dos artigos de Shoes) eu entendi que Service é conceito de domínio e portanto deve ser desacoplado de tecnologia.
O que raciocinei é que o ApplicationLayer seria o equivalente do ServiceLayer do Fowler, e que ele seria aquela parte que traz inerente a tecnologia específica. Por exemplo o sessionbean em java, ou o remoting do .net, ou o com+ do .net ou o webservice, etc.
+1
BiraBoy wrote:Pode um destes conceito estar presente dentro do outro?
A relação entre Service/Application Layer e Services DDD se dá como qualquer outra relação entre camadas, já que services DDD pertecem obrigatoriamente à camada de domínio.
BiraBoy wrote:Como se separa o ApplicationLayer do DomainLayer em DDD?
Hmm.. Em Java eu uso estrutura de pacotes.
BiraBoy wrote:Que padrões se utiliza para fazer o ApplicationLayer?
Qualquer um, desde que seja útil pra você em determinada situação.
BiraBoy wrote:o ApplicationLayer seria os actions struts ou os managed beans do JSF, ou é outra classe?
Pra mim isso é camada de apresentação, o que acha?
|
|
|
|
Lezinho wrote:Aiaiai ...
Services são Services. Existem de aplicação e de negócio, não sei onde esta a complicação disso. Tanto o DDD quanto o PoEAA comentam dos dois.
De fato Phillip, a discussão era de Manga e já estamos falando de Banana.
Desnecessário seus gemidos... Inclusive, é lamentável a atitude de desdém das pessoas quando questionadas quanto a sua interpretação sobre os textos mencionados.
Você não percebe mas a complicação está no fato de você não conseguir explicar com clareza a diferença entre a camada Service e Application. Talvez porque não haja. Você cita duas fontes que definem a mesma coisa com 2 nomes, reconhecidamente um conflito na nomenclatura atual senão, vamos lá, precisamos ter claro as responsabilidades de cada camada, mas esse não parece ser o caso, pelo contraráio, você parece ignorar princípios importantes como YAGNI e KISS e se justifica colando citações sem contexto do seu autor preferido.
Talvez o tamanho dessa thread tenha feito você perder o foco mas eu vou tentar ser ainda mais claro:
Eu considero as camadas Service e Application como a mesma e não sinto falta de outra camada.
Pense que existem pessoas que estão interessadas em comecar a aplicar práticas mais modernas para o seu projeto de software OO e precisam competir com as tais arquiteturas de "referência" estabelecidas. Eu não vejo como essa camada adicional pode ajudar essas pessoas a melhor organizar sua arquitetura usando apenas o seu argumento de que tem que ser assim porque o mestre mandou.
|
|
|
|
pcalcado wrote:Camadas (Layers) é um padrão sim
Eu quis dizer que fowler não define Service Layer como um padrão de domain model (ou um "building block" como Evans define seus padrões)
Services de DDD pertencem ao domínio do problema e por isso podem existir entities que dependam de tais Services.
|
|
|
|
Lezinho wrote:"Client Layer"?
Client Layer é qualquer camada que faça uso de outra camada...
Quem disse o contrário?
Lezinho wrote:Um repositório pode ser client de um DAo, uma Entity pode ser cliente de um VO, um Aggregate pode ser client de um Entity ...
Estamos falando de camadas; repositório não é camada, entity não é camada, aggregate não é camada.. Isso sim é padrão 
Lezinho wrote:"Camada de aplicação" é aquela relevante ao contexto da aplicação (ManagedBeans, Actions) ou aquelas que server como uma Supercamada para a de Serviços, oferecendo suporte como de email, ftp, etc (de nada tem haver com o negócio).
Aqui deu a entender que seus Actions poderiam estar na camada de aplicação. O que não é o caso certo?
Lezinho wrote:
Domain Driven Design wrote:"While using Services, is important to keep the domain layer
isolated. It is easy to get confused between services which
belong to the domain layer, and those belonging to the
infrastructure. There can also be services in the application layer
which adds a supplementary level of complexity."
Quem está dizendo que os Services são os mesmos é você. Agora já temos 3 services. Sua citação confirma que Services do DDD não é o Service Layer. Ou seja, nada impede que tenhamos entities chamando repositorioes ou entities chamando services ja que estamos falando estritamente de services "which belong to the domain layer".
|
|
|
|
Lezinho wrote:
cmoscoso wrote:"O que Fowler descreve não é um padrão, mas uma camada..."
Se não é um padrão, então tente dizer isso a Randy Sttaford, que descreve a no POAA a literal diferença entre o "PATTERN" Session Façade e o "PATTERN" Service Layer, exatamente com estas palavras. Neste mesmo capítulo é mencionada a Application Layer, tendo como a ServiceLayer a ponte entre esta e a modelo de domínio.
Você quer dizer então que Application Layer é a Client Layer? Sério, não entendo sua interpretação de Application Layer.
No link da minha resposta anterior tem uma citação desse cara sobre Services Layer: "Defines an application's boundary with a layer of services that establishes a set of available operations and coordinates the application's response in each operation."
Lezinho wrote:O Domain Driven Design diz que:
"A Service usually becomes a point of connection for many objects"
... exatamente como um objeto da ServiceLayer, onde que não tendo lógica de negócio, delega essa aos objetos do domínio.
Uma definição mais clara seria: Um Service (DDD) é um ponto de conexão para vários objetos (de domínio) que compartilham de uma mesma regra de negócio. Observe que não saímos do domain layer aqui.
A diferença fica evidente se dissermos que um Service (DDD) poderia ser chamado da Service/Applcation Layer, mas o contrário não deveria ser permitido se você considerar uma premissa básica da separação em camadas: Dependência apenas de camadas abaixo.
Services e Repositorios pertecem ao domínio
Service/Application Layer NÃO pertece ao domínio (apesar de fazer uso do mesmo)
|
|
|
|
Lezinho wrote:
Domain Driven Design Quickly wrote:A service is not about the object performing
the service, but is related to the objects the operations are
performed on/for. In this manner, a Service usually becomes a
point of connection for many objects.
rodrigoy, como você pode ver na citação acima, um service do DDD é um ponto de conexão de vários outros objetos, afim de fornecer uma determinada operação. Muita semelhança com o padrão descrito por Fowler, não concorda?
Quanto a nele conter os objetos de domínio ou os objetos de domínio conter eles:
Domain Driven Design Quickly wrote:The operation performed refers to other objects in the domain.
A execução da operação do Service é referenciada para outros objetos no domínio.
O que Fowler descreve não é um padrão, mas uma camada... No DDD, services são conceitos do domínio, assim como repositórios e entities.
Services Layer (também conhecido como Application Layer) não deve ter regras de negócio (apesar de que do ponto de vista do cliente é indiferente). O papel do services como camada é a coordenação de fluxos e responder às solicitações, eventualmente entrando na camada de domínio.
Ou seja, de semelhante só tem o nome.. Por isso prefiro o termo Application Layer.
|
|
|
|
|
|