Gostaria da opinião e crítica sobre uma arquitetura que foi projetada recentemente aqui na empresa,
esta provê uma solução para problemas de interfaces unindo sobre uma run-time ou não componentes em HTML/AJAX e Flex.
Na camada de Aplicação se encontra ExceptionsHandlers que são programadas com Aspectos assim como Logs e etc…
O domínio foi projetado baseado no DomainDrivenDesing, logo as classes ali são somente POJOS e injetadas via IoC do Spring.
Na infraestrutura contém apenas possíveis implementações do repository que faz uso das classes abstratas do Spring para acessos JDBC ou componentes que o Spring contém como acessos a serviços via JMI.
É uma explanação sucinta, mas segue abaixo uma representação do modelo.
Poderia explicar melhor a frase "esta provê uma solução para problemas de interfaces unindo sobre uma run-time ou não componentes em HTML/AJAX e Flex. " ?
le-silva: Poderia explicar melhor o porque das arquiteturas de referencia serem uma má ideia? Creio que uma arquitetura unica e burra deve sempre ser evitada, porém em grande parte dos casos uma arquitetura de referencia resolve o problema(leia-se multavel, expansivel, passivel de melhorias).
[quote=aleck]Poderia explicar melhor a frase "esta provê uma solução para problemas de interfaces unindo sobre uma run-time ou não componentes em HTML/AJAX e Flex. " ?
le-silva: Poderia explicar melhor o porque das arquiteturas de referencia serem uma má ideia? Creio que uma arquitetura unica e burra deve sempre ser evitada, porém em grande parte dos casos uma arquitetura de referencia resolve o problema(leia-se multavel, expansivel, passivel de melhorias).
[/quote]
alguns pontos:
:arrow: use JSON ou algum outro protocolo que seja de facil consumo tanto pelo Flash/Flex/Air quanto pelos componentes AJAX, para evitar ao maximo o retrabalho. Creio que esse data service que deveria prover isso.
:arrow: Se esta usando DDD, as classes realmente de Domain voce mal vai precisar de IOC, deve dar para fazer o wiring na mao e deixar o codigo muito legivel. o IOC seria mais util para seus servicos, nao?
alias, que programa voce usou para desenhar? ficou muito bom, parabens
[quote=le-silva][quote=aleck]Poderia explicar melhor a frase "esta provê uma solução para problemas de interfaces unindo sobre uma run-time ou não componentes em HTML/AJAX e Flex. " ?
le-silva: Poderia explicar melhor o porque das arquiteturas de referencia serem uma má ideia? Creio que uma arquitetura unica e burra deve sempre ser evitada, porém em grande parte dos casos uma arquitetura de referencia resolve o problema(leia-se multavel, expansivel, passivel de melhorias).
[/quote]
Acho que você entendeu errado, arquitetura de referencia é uma arquitetura montada especificamente para atender um negocio ou uma serie de projetos que sejam comuns a um cliente, tendo como base a analise e estudo das necessidades. Os links acima fazem alusão a uma arquitetura utilizada para qualquer projeto, visando abraçar o mundo e qualquer negocio.
Este não é o caso do criador do post, pois esta arquitetura atende em especifico o negocio dele e poderia ser utilizada em todos os projetos que seguem o mesmo padrão, de maneira alguma visa resolver os problemas do mundo ou a paz mundial.
Só pra entender melhor, a idéia é que ela seja uma arquitetura de referência, ou ela foi projetada para uma aplicação especifica?
Arquiteturas referência nunca são uma boa idéia…[/quote]
A principio é para atender os problemas de migração, pois existem muitos componentes feitos com html, e estamos visando o reuso destes.
Através do AIR, posso executar tanto componentes puro html, puro Flex, ou então tudo junto, como estou programando para uma run-time, elimina a preocupação de desenvolver compatibilidades entre browsers, fora outros ganhos de aplicações off-line ou de acesso ao S.O.
Com o Blaze eu posso prover acessos ao AIR/ ou Browser tanto RemoteObject, tanto WebServices, tanto HttpService, a diferença só ficará na façade, no caso se uma app for voltada apenas para Flex, este irá acessar direto o Service do domínio, se não criaremos um controller que faz o tratamentos dos request’s e responses do html.
Não posso me apegar somente ao Flex, pois existem muitos componentes em html já feitos.
Correto, o DataService abstrai solicitações via RemoteObject (AMF3), WebServices, HttpService.
Estou usando Spring com Annotations logo não me encomodo de "acoplar" um @AutoWired para realizar as injeções.
Fiz uso do Gliffy -> http://www.gliffy.com/ App baseada em RIA feita em Laszlo, é muito bom por sinal.
Só pra entender melhor, a idéia é que ela seja uma arquitetura de referência, ou ela foi projetada para uma aplicação especifica?
Arquiteturas referência nunca são uma boa idéia…[/quote]
Não!? Pq vc acha isso!?
Há uma grande diferença entre uma “arquitetura de referência” e um “framework de referência” (se é que pode-se dizer que um framework é de referência). Também não confunda “arquitetura de referência” com os frameworks Franksteins do tipo jCompany.
Estava até pensando: “Hoje trabalho com Hibernate. Acho que vou sugerir que o próximo projeto utilize Kodo. Depois podemos fazer outro com Toplink. Vai ficar uma coisa bem bonita de se ver.”
Gostaria da opinião e crítica sobre uma arquitetura que foi projetada recentemente aqui na empresa,
esta provê uma solução para problemas de interfaces unindo sobre uma run-time ou não componentes em HTML/AJAX e Flex.
[/quote]
Fala ai rpffoz !!!
:arrow: Critica :Mais uma boa contribuição de qualidade no GUJ
:idea: Opinião: “Mesmo havendo um paradigma dos Requisitos e legados para cada Corporação eu percebo um business plann bem elaborado, para se refletir”
Isso mesmo Parabens !!! “Como dizem uma Imagem já fala por 1.000 palavras…”
Não entendi, eu posso escrever código em JavaScript que acessa as coisas do Blaze ou eu teria que fazer alguma coisa por fora pra as visualizações em HTML?
De qualquer forma, porque vocês escolheram manter essas duas linhas de desenvolvimento pra camada de visualização? Algum motivo especial?
[quote=aleck][quote=le-silva][quote=aleck]Poderia explicar melhor a frase "esta provê uma solução para problemas de interfaces unindo sobre uma run-time ou não componentes em HTML/AJAX e Flex. " ?
le-silva: Poderia explicar melhor o porque das arquiteturas de referencia serem uma má ideia? Creio que uma arquitetura unica e burra deve sempre ser evitada, porém em grande parte dos casos uma arquitetura de referencia resolve o problema(leia-se multavel, expansivel, passivel de melhorias).
[/quote]
Acho que você entendeu errado, arquitetura de referencia é uma arquitetura montada especificamente para atender um negocio ou uma serie de projetos que sejam comuns a um cliente, tendo como base a analise e estudo das necessidades. Os links acima fazem alusão a uma arquitetura utilizada para qualquer projeto, visando abraçar o mundo e qualquer negocio.
Este não é o caso do criador do post, pois esta arquitetura atende em especifico o negocio dele e poderia ser utilizada em todos os projetos que seguem o mesmo padrão, de maneira alguma visa resolver os problemas do mundo ou a paz mundial.
[/quote]
Eu entendi errado? Eu nem sequer disse o que eu entendo por arquitetura de referência. Eu disse, sim, que arquiteturas de referência não são boa idéia. E como você me pediu uma explicação sobre minha opinião, te dei alguns links pra você ler e tirar suas próprias conclusões. Afinal, este assunto já foi discutido aqui no GUJ e nosso colega Shoes também escreveu um post sobre isso.
Mas o que eu penso? Não vou chover no molhado, o post do Shoes diz muito do que eu penso…
Guias e modelos são bons (aliás é pra isso que servem os architectural patterns). Ter uma arquitetura única para todas aplicações, é mal, porque nem todas as aplicações são iguais.
Quer saber? Já sofri muuuuito em projetos com arquitetos Mc Donalds.
Agora, quando ao trabalho do nosso colega Rodrigo, eu pedi que ele dissesse qual o objetivo desta arquitetura, e ele prontamente deu uma ótima resposta.
Pelo que entendi da explicação dele, o objetivo desta arquitetura não é ser uma arquitetura Mc Donalds, ou de referência - como queira chamar. Ela tem um objetivo bem especifico mapeado.
Acho que vc precisa de consolo e não de argumentação consistente. Se encontrou no tal artigo, ótimo.
A arquitetura é de REFERÊNCIA pq determina quais frameworks, padrões, protocolos, guidelines, implementações de referência, etc, etc a serem utilizados no projeto.
Seguindo o padrão DDD, vc pode de fato desenvolver suas regras de negócio sem preocupar-se onde persistirá os dados e que forma fará a view.
Podendo separar equipes com funções bem distintas em um projeto.
Quer saber? Já sofri muuuuito em projetos com arquitetos Mc Donalds.
[/quote]
Acho que vc precisa de consolo e não de argumentação consistente. Se encontrou no tal artigo, ótimo.
A arquitetura é de REFERÊNCIA pq determina quais frameworks, padrões, protocolos, guidelines, implementações de referência, etc, etc a serem utilizados no projeto.[/quote]
Taz não é esse o conceito que foi cunhado como arquitetura de referência. Dê uma olhadinha nos links que indiquei.
Mas, de qualquer forma, se não for pedir de mais, nos apresente a sua argumentação consistente…
Quer saber? Já sofri muuuuito em projetos com arquitetos Mc Donalds.
[/quote]
Acho que vc precisa de consolo e não de argumentação consistente. Se encontrou no tal artigo, ótimo.
A arquitetura é de REFERÊNCIA pq determina quais frameworks, padrões, protocolos, guidelines, implementações de referência, etc, etc a serem utilizados no projeto.[/quote]
Taz não é esse o conceito que foi cunhado como arquitetura de referência. Dê uma olhadinha nos links que indiquei.
Mas, de qualquer forma, se não for pedir de mais, nos apresente a sua argumentação consistente…[/quote]
Se vc acredita em tudo que te falaram, também deve acreditar em Papai Noel.
Sugiro que vc procure por “argumentação consistente” (Google -> “reference architecture” traz mais de 47000 resultados) e tenha um ponto de vista crítico em relação às coisas que lê.
Isso mesmo Parabens !!! 