O grupo no qual você está postando é um grupo da Usenet. As mensagens postadas neste grupo farão com que o seu e-mail fique visível para qualquer pessoa na internet.
___________________________________________________________________________ _________ Veja quais são os assuntos do momento no Yahoo! +Buscados http://br.maisbuscados.yahoo.com
Realmente é impressionante como este assunto vai e volta nesta lista e
aparentemente em toda a comunidade de desenvolvedores do mundo... :-).
Pra mim este assunto é fascinante. O agumento contra anemic models é sólido,
mas somente à primeira vista. Como o próprio artigo e o Fowler citam, a
longo prazo o que temos é objetos complexos, cheios de regras que ninguem
sabe onde e quando usar e algo que era pra ser um POCO se transforma em um
mini-monstrinho... (e o próprio autor se coloca ele como inexperiente em
dominios ricos.... quero ver o blog dele daqui a 2 ou 3 anos se permanece o
mesmo! :-))
Apesar de vários defenderem nesta lista o uso de modelos ricos, até hoje eu
não vi um único exemplo de uma aplicação de médio ou grande porte (.net,
claro), que esteja em produção, e que faça uso de domínio rico de maneira
consistente. Todos os exemplos são academicos, de pequenos sistemas ou
simplesmente provas de conceito.
Esta questão dos objetos se tornarem inchados, da dificuldade em fazer algo
prático para controlar os aspectos do serviços (transação, log etc) e o
própria localização das regras (qual objeto faz o que) pra mim torna um
modelo rico sempre um pesadelo de manutenção.
realmente o assunto tem muito o que ser falado, discutido, emfim, esclarecido, já que ainda não é de dominio da maioria dos desenvolvedores, e não adianta ser somente de dominio de alguns poucos Seniors e Arquitetos tem que ter o entendimento verdadeiro de todos os envolvidos no desenvolvimento de sw.
Eu estou com vc, ainda dou preferencia ao modelo anemico, sou adepto do principio KISS
(Keep It Simple).
[]´s
Edmilson
--- Em sáb, 17/10/09, Alexandre Valente <alexandre.g.vale...@gmail.com> escreveu:
De: Alexandre Valente <alexandre.g.vale...@gmail.com>
Assunto: [dotnetarchitects] Re: Domain Models, Anemic Domain Models and Transaction Scripts
Para: dotnetarchitects@googlegroups.com
Data: Sábado, 17 de Outubro de 2009, 16:59
Realmente é impressionante como este assunto vai e volta nesta lista e aparentemente em toda a comunidade de desenvolvedores do mundo... :-).
Pra mim este assunto é fascinante. O agumento contra anemic models é sólido, mas somente à primeira vista. Como o próprio artigo e o Fowler citam, a longo prazo o que temos é objetos complexos, cheios de regras que ninguem sabe onde e quando usar e algo que era pra ser um POCO se transforma em um mini-monstrinho... (e o próprio autor se coloca ele como inexperiente em dominios ricos.... quero ver o blog dele daqui a 2 ou 3 anos se permanece o mesmo! :-))
Apesar de vários defenderem nesta lista o uso de modelos ricos, até hoje eu não vi um único exemplo de uma aplicação de médio ou grande porte (.net, claro), que esteja em produção, e que faça uso de domínio rico de maneira consistente. Todos os exemplos são academicos, de pequenos sistemas ou simplesmente provas de conceito.
Esta questão dos objetos se tornarem inchados, da dificuldade em fazer algo prático para controlar os aspectos do serviços (transação, log etc) e o própria localização das regras (qual objeto faz o que) pra mim torna um modelo rico sempre um pesadelo de manutenção.
Veja quais são os assuntos do momento no Yahoo! + Buscados: Top 10 - Celebridades - Música - Esportes
___________________________________________________________________________ _________
Veja quais são os assuntos do momento no Yahoo! +Buscados
http://br.maisbuscados.yahoo.com
> realmente o assunto tem muito o que ser falado, discutido, emfim,
> esclarecido, já que ainda não é de dominio da maioria dos desenvolvedores, e
> não adianta ser somente de dominio de alguns poucos Seniors e Arquitetos tem
> que ter o entendimento verdadeiro de todos os envolvidos no desenvolvimento
> de sw.
> Eu estou com vc, ainda dou preferencia ao modelo anemico, sou adepto do
> principio KISS
> (Keep It Simple).
> []´s
> Edmilson
> --- Em *sáb, 17/10/09, Alexandre Valente <alexandre.g.vale...@gmail.com>*escreveu:
> De: Alexandre Valente <alexandre.g.vale...@gmail.com>
> Assunto: [dotnetarchitects] Re: Domain Models, Anemic Domain Models and
> Transaction Scripts
> Para: dotnetarchitects@googlegroups.com
> Data: Sábado, 17 de Outubro de 2009, 16:59
> Realmente é impressionante como este assunto vai e volta nesta lista e
> aparentemente em toda a comunidade de desenvolvedores do mundo... :-).
> Pra mim este assunto é fascinante. O agumento contra anemic models é
> sólido, mas somente à primeira vista. Como o próprio artigo e o Fowler
> citam, a longo prazo o que temos é objetos complexos, cheios de regras que
> ninguem sabe onde e quando usar e algo que era pra ser um POCO se transforma
> em um mini-monstrinho... (e o próprio autor se coloca ele como inexperiente
> em dominios ricos.... quero ver o blog dele daqui a 2 ou 3 anos se permanece
> o mesmo! :-))
> Apesar de vários defenderem nesta lista o uso de modelos ricos, até hoje eu
> não vi um único exemplo de uma aplicação de médio ou grande porte (.net,
> claro), que esteja em produção, e que faça uso de domínio rico de maneira
> consistente. Todos os exemplos são academicos, de pequenos sistemas ou
> simplesmente provas de conceito.
> Esta questão dos objetos se tornarem inchados, da dificuldade em fazer algo
> prático para controlar os aspectos do serviços (transação, log etc) e o
> própria localização das regras (qual objeto faz o que) pra mim torna um
> modelo rico sempre um pesadelo de manutenção.
Não esqueci não, opto sempre por não escrever o ultimo S, para não ofender ninguem.
=)
Edmilson
--- Em sáb, 17/10/09, Juan Pedro A. Lopes <zerova...@gmail.com> escreveu:
De: Juan Pedro A. Lopes <zerova...@gmail.com>
Assunto: [dotnetarchitects] Re: Domain Models, Anemic Domain Models and Transaction Scripts
Para: dotnetarchitects@googlegroups.com
Data: Sábado, 17 de Outubro de 2009, 18:10
Esqueceu do "stupid" :P
"Keep It Simple, Stupid"
2009/10/17 edmilson hora <edmilson_h...@yahoo.com.br>
Alexandre,
realmente o assunto tem muito o que ser falado, discutido, emfim, esclarecido, já que ainda não é de dominio da maioria dos desenvolvedores, e não adianta ser somente de dominio de alguns poucos Seniors e Arquitetos tem que ter o entendimento verdadeiro de todos os envolvidos no desenvolvimento de sw.
Eu estou com vc, ainda dou preferencia ao modelo anemico, sou adepto do principio KISS
(Keep It Simple).
[]´s
Edmilson
--- Em sáb, 17/10/09, Alexandre Valente <alexandre.g.vale...@gmail.com> escreveu:
De: Alexandre Valente <alexandre.g.vale...@gmail.com>
Assunto: [dotnetarchitects] Re: Domain Models, Anemic Domain Models and Transaction Scripts
Para: dotnetarchitects@googlegroups.com
Data: Sábado, 17 de Outubro de 2009, 16:59
Realmente é impressionante como este assunto vai e volta nesta lista e aparentemente em toda a comunidade de desenvolvedores do mundo... :-).
Pra mim este assunto é fascinante. O agumento contra anemic models é sólido, mas somente à primeira vista. Como o próprio artigo e o Fowler citam, a longo prazo o que temos é objetos complexos, cheios de regras que ninguem sabe onde e quando usar e algo que era pra ser um POCO se transforma em um mini-monstrinho... (e o próprio autor se coloca ele como inexperiente em dominios ricos.... quero ver o blog dele daqui a 2 ou 3 anos se permanece o mesmo! :-))
Apesar de vários defenderem nesta lista o uso de modelos ricos, até hoje eu não vi um único exemplo de uma aplicação de médio ou grande porte (.net, claro), que esteja em produção, e que faça uso de domínio rico de maneira consistente. Todos os exemplos são academicos, de pequenos sistemas ou simplesmente provas de conceito.
Esta questão dos objetos se tornarem inchados, da dificuldade em fazer algo prático para controlar os aspectos do serviços (transação, log etc) e o própria localização das regras (qual objeto faz o que) pra mim torna um modelo rico sempre um pesadelo de manutenção.
___________________________________________________________________________ _________
Veja quais são os assuntos do momento no Yahoo! +Buscados
http://br.maisbuscados.yahoo.com
O assunto vai e volta porque todos que o escutam não o entendem
completamente.
Acredito que até os que dizem saber, não tem noção que tem apenas uma
pequena
visão superficial do assunto.
Eu mesmo penei para entender muita coisa e ainda estou estudando. É claro
que no
meu tempo e de acordo com a minha força de vontade.
Estou lendo vários livros (diversas vezes por causa da falta de atenção) e
ainda tem
alguns na fila. Contudo, não me engano, ainda vou ter muitos e muitos livros
pra ler.
Pelo menos, sempre soube que tenho muito que estudar para estar atualizado.
Por isso, continue assim que a jornada é longa...
Peneluc
2009/10/17 edmilson hora <edmilson_h...@yahoo.com.br>
> Não esqueci não, opto sempre por não escrever o ultimo S, para não ofender
> ninguem.
> =)
> Edmilson
> --- Em *sáb, 17/10/09, Juan Pedro A. Lopes <zerova...@gmail.com>*escreveu:
> De: Juan Pedro A. Lopes <zerova...@gmail.com>
> Assunto: [dotnetarchitects] Re: Domain Models, Anemic Domain Models and
> Transaction Scripts
> Para: dotnetarchitects@googlegroups.com
> Data: Sábado, 17 de Outubro de 2009, 18:10
> 2009/10/17 edmilson hora <edmilson_h...@yahoo.com.br<http://br.mc334.mail.yahoo.com/mc/compose?to=edmilson_h...@yahoo.com.br>
>> Alexandre,
>> realmente o assunto tem muito o que ser falado, discutido, emfim,
>> esclarecido, já que ainda não é de dominio da maioria dos desenvolvedores, e
>> não adianta ser somente de dominio de alguns poucos Seniors e Arquitetos tem
>> que ter o entendimento verdadeiro de todos os envolvidos no desenvolvimento
>> de sw.
>> Eu estou com vc, ainda dou preferencia ao modelo anemico, sou adepto do
>> principio KISS
>> (Keep It Simple).
>> Realmente é impressionante como este assunto vai e volta nesta lista e
>> aparentemente em toda a comunidade de desenvolvedores do mundo... :-).
>> Pra mim este assunto é fascinante. O agumento contra anemic models é
>> sólido, mas somente à primeira vista. Como o próprio artigo e o Fowler
>> citam, a longo prazo o que temos é objetos complexos, cheios de regras que
>> ninguem sabe onde e quando usar e algo que era pra ser um POCO se transforma
>> em um mini-monstrinho... (e o próprio autor se coloca ele como inexperiente
>> em dominios ricos.... quero ver o blog dele daqui a 2 ou 3 anos se permanece
>> o mesmo! :-))
>> Apesar de vários defenderem nesta lista o uso de modelos ricos, até hoje
>> eu não vi um único exemplo de uma aplicação de médio ou grande porte (.net,
>> claro), que esteja em produção, e que faça uso de domínio rico de maneira
>> consistente. Todos os exemplos são academicos, de pequenos sistemas ou
>> simplesmente provas de conceito.
>> Esta questão dos objetos se tornarem inchados, da dificuldade em fazer
>> algo prático para controlar os aspectos do serviços (transação, log etc) e o
>> própria localização das regras (qual objeto faz o que) pra mim torna um
>> modelo rico sempre um pesadelo de manutenção.
> [Como o] Fowler citam [cita], a longo prazo o que temos é objetos complexos, cheios de regras que ninguem sabe onde e quando usar e algo que era pra ser um POCO se transforma em um mini-monstrinho... (e o próprio autor se coloca ele como inexperiente em dominios ricos.... quero ver o blog dele daqui a 2 ou 3 anos se permanece o mesmo! :-))
Desculpe mas você pode me passar uma referência para isso? A questão de "se transformar em um mini-monstrinho" é sintoma de problemas de modelagem clássicos e já catalogados e estudados à exaustão. O mesmo ocorre com sistemas procedurais -confira os livros de Ed Yourdon.
Mas eu entendo seu argumento. Eu trabalhei um tempo considerável programando em C e este é o mesmo argumento que as pessoas utilizavam para não utilizar nenhuma outra linguagem. E, como você mesmo disse, acho que o problema é falta de referências -apesar de que também faltam referências seguindo seu critério para programação procedural.
Infelizmente acaba virando um problema de ovo-e-galinha, creio, porque para você ver um sistema assim para usar como refer6encia você ou cai em um lugar onde tal coisa já exista ou começa a usar antes de ver uma referência.
No próprio artigo citado pelo Edmilson, tem uma frase tirada do livro do
Fowler (fantástico aliás), "Patterns of Enterprise Applications
Architecture", onde ele fala disto (abaixo). Aliás, a minha opinião é que
este é o problema que levou à criação da camada de serviços no DDD, mas isto
é outra thread... :-)
A common concern with domain logic is bloated domain objects. As you build
a screen to manipulate your orders you'll notice that some of the order
behavior is only needed for it. If you put these responsibilities on the
order, the risk is that the Order class will become too big because it's
full of responsibilities that are only used in a single use case. This
concern leads people to consider whether some responsibility is general, in
which case it should sit in the order class, or specific, in which case it
should sit in some usage-specific class, which might be a Transaction Script
or perhaps the presentation itself.
Agora negativo, embora faltem exemplos de aplicações maiores usando modelo
rico, eu posso te citar dezenas de exemplos usando regras de negócio na
forma Transaction Scripts. Eu mesmo tenho 2 aplicações de médio porte, com
quase 10 anos cada, estuturada desta forma (utilizada por centenas de
usuários simulaneos, atualmente). E em nenhuma delas eu tenho problema de
duplicação de código, ou complexidade de código excessiva.
Finalmente, um ponto importante é que pra mim isto vale só pra regras de
negócio. Todos os demais componentes do sistemas, controllers, infra, DTOs,
etc. fazem uso massivo de OO e são objetos ricos. O meu problema é SOMENTE
com as regras de negócio.....
abs
> 2009/10/18 Alexandre Valente <alexandre.g.vale...@gmail.com>
> > [Como o] Fowler citam [cita], a longo prazo o que temos é objetos
> complexos, cheios de regras que ninguem sabe onde e quando usar e algo que
> era pra ser um POCO se transforma em um mini-monstrinho... (e o próprio
> autor se coloca ele como inexperiente em dominios ricos.... quero ver o blog
> dele daqui a 2 ou 3 anos se permanece o mesmo! :-))
> Desculpe mas você pode me passar uma referência para isso? A questão
> de "se transformar em um mini-monstrinho" é sintoma de problemas de
> modelagem clássicos e já catalogados e estudados à exaustão. O mesmo
> ocorre com sistemas procedurais -confira os livros de Ed Yourdon.
> Mas eu entendo seu argumento. Eu trabalhei um tempo considerável
> programando em C e este é o mesmo argumento que as pessoas utilizavam
> para não utilizar nenhuma outra linguagem. E, como você mesmo disse,
> acho que o problema é falta de referências -apesar de que também
> faltam referências seguindo seu critério para programação procedural.
> Infelizmente acaba virando um problema de ovo-e-galinha, creio, porque
> para você ver um sistema assim para usar como refer6encia você ou cai
> em um lugar onde tal coisa já exista ou começa a usar antes de ver uma
> referência.
> No próprio artigo citado pelo Edmilson, tem uma frase tirada do livro do > Fowler (fantástico aliás),
O problema é que o parágrafo citado está fora de contexto. O trecho que falta, o parágrafo que vem logo depois do que você colou, está de acordo com o que outros, o Giovanni se não me engano, falaram antes:
"The problem with separating usage-specific behavior is that it can lead to duplication. Behavior that’s separated from the order is harder to find, so people tend to not see it and duplicate it instead. Duplication can quickly lead to more complexity and inconsistency, but I’ve found that bloating occurs much less fre- quently than predicted. If it does occur, it’s relatively easy to see and not difficult to fix. My advice is not to separate usage-specific behavior. Put it all in the object that’s the natural fit. Fix the bloating when, and if, it becomes a problem."
E para o problema de "lógica de processo" existem diversas soluções disponíveis. Uma delas, proposta por Domain Driven Design, está na forma do pattern Service.
> Agora negativo, embora faltem exemplos de aplicações maiores usando modelo > rico, eu posso te citar dezenas de exemplos usando regras de negócio na > forma Transaction Scripts.
Acho que não me fiz entender. O difícil é achar uma aplicação para a qual eu possa te passar um link aqui agora e você ir entender como as coisas funcionam -e até onde sei isto também é verdade para aplicações procedurais. Isto não quer dizer que eu não conheça e/ou trabalhe com este tipo de aplicação -e ha muitos anos que o faço. Inclusive já citei algumas aqui em uma das muitas thread sobre este tema.
Oi Phillip,
Exato, mas o ponto é que eu vejo justamente o efeito contrário, modelos
ricos são mais complexos de evoluir e manter.
Quanto ao exemplo, não precisa pasasr um link. Basta citar o exemplo e dizer
como a aplicação é estruturada. Como é a parte de transações é tratada (quem
inicia, quem garante, quem trata erro), como é feito log de regras de
negócio, qual o critério para definir qual objeto é responsável por qual
ação de negócio, como evoluir isto no tempo, como compor ações complexas com
vários objetos.
Acho que algúem que perdesse um tempo listando todos estes pontos de uma
aplicação baseada em modelo rico prestaria um grande serviço a esta
comunidade (e talvez até pudesse acabar com esta discussão de uma vez por
todas! :-)). Agora não dá pra ser exemplo academico nem conceitual pois,
como falei, em teoria faz sentido, em uma aplicação pequena faz sentido, mas
a longo prazo conforme a aplicação cresce, a coisa se complica bem...daí a
importância de ser uma aplicação em produção, pq se alguem resolveu todos
estes problemas e a coisa continua funcionando (sem que se tenha voltado
para transaction scripts! :-)), realmente aí vale a pena dar uma olhada.
> 2009/10/18 Alexandre Valente <alexandre.g.vale...@gmail.com>:
> > No próprio artigo citado pelo Edmilson, tem uma frase tirada do livro do
> > Fowler (fantástico aliás),
> O problema é que o parágrafo citado está fora de contexto. O trecho
> que falta, o parágrafo que vem logo depois do que você colou, está de
> acordo com o que outros, o Giovanni se não me engano, falaram antes:
> "The problem with separating usage-specific behavior is that it can lead to
> duplication. Behavior that’s separated from the order is harder to
> find, so people
> tend to not see it and duplicate it instead. Duplication can quickly
> lead to more
> complexity and inconsistency, but I’ve found that bloating occurs much
> less fre-
> quently than predicted. If it does occur, it’s relatively easy to see
> and not difficult
> to fix. My advice is not to separate usage-specific behavior. Put it all
> in the object
> that’s the natural fit. Fix the bloating when, and if, it becomes a
> problem."
> E para o problema de "lógica de processo" existem diversas soluções
> disponíveis. Uma delas, proposta por Domain Driven Design, está na
> forma do pattern Service.
> > Agora negativo, embora faltem exemplos de aplicações maiores usando
> modelo
> > rico, eu posso te citar dezenas de exemplos usando regras de negócio na
> > forma Transaction Scripts.
> Acho que não me fiz entender. O difícil é achar uma aplicação para a
> qual eu possa te passar um link aqui agora e você ir entender como as
> coisas funcionam -e até onde sei isto também é verdade para aplicações
> procedurais. Isto não quer dizer que eu não conheça e/ou trabalhe com
> este tipo de aplicação -e ha muitos anos que o faço. Inclusive já
> citei algumas aqui em uma das muitas thread sobre este tema.
> Quanto ao exemplo, não precisa pasasr um link. Basta citar o exemplo e dizer > como a aplicação é estruturada. Como é a parte de transações é tratada (quem > inicia, quem garante, quem trata erro), como é feito log de regras de > negócio, qual o critério para definir qual objeto é responsável por qual > ação de negócio, como evoluir isto no tempo, como compor ações complexas com > vários objetos.
Tinha impressão que já tínhamos discutido exemplos em diversas outras threads... algo em específico?
> 2009/10/4 Alexandre Valente <alexandre.g.vale...@gmail.com>: >> Tipo como é feito a parte de >> validação na camada de interface, como é tratado a questão de >> serialização/deserializaçào para integração, como é feito o controle de >> transação/validação e etc...
> No início da thread eu linkei para um artigo que explica como > validações são feitas na Camada de Negócios ( > http://fragmental.tw/2009/08/21/ubiquitous-language-tiny-types-and-re... > ). Na Camada de Apresentação ele depende da aplicação, geralmente > JavaScript para web e Specifications para clientes desktop. A > integração entre partes do mesmo sistema é feita via REST (completo, > incluindo HATEOAS), com outros sistemas depende do que este faz > disponível. Não sei exatamente o que você quer dizer com "controle de > transação" mas no geral uma transação (do NHibernate, não > necessariamente do banco) é aberta no início do Request e fechada no > final.
> Todos os sistemas utilizam Domain Model e Domain-Drivel Design, > NHibernate e ASP.Net MVC. Alguns utilizam WPF e Silverlight.
Oi Phillip,
Sim, e como das outras vezes, nada pessoal mas exemplos teóricos, artigos,
patterns, aplicações conceituais e etc. não adiantam. Como falei, é tudo
muito bonito e legal na teoria, mas quero ver como (e se) os problemas
práticos foram resolvidos em aplicações reais, médias ou grandes, em
produção.
> 2009/10/18 Alexandre Valente <alexandre.g.vale...@gmail.com>:
> > Quanto ao exemplo, não precisa pasasr um link. Basta citar o exemplo e
> dizer
> > como a aplicação é estruturada. Como é a parte de transações é tratada
> (quem
> > inicia, quem garante, quem trata erro), como é feito log de regras de
> > negócio, qual o critério para definir qual objeto é responsável por qual
> > ação de negócio, como evoluir isto no tempo, como compor ações complexas
> com
> > vários objetos.
> Tinha impressão que já tínhamos discutido exemplos em diversas outras
> threads... algo em específico?
> > 2009/10/4 Alexandre Valente <alexandre.g.vale...@gmail.com>:
> >> Tipo como é feito a parte de
> >> validação na camada de interface, como é tratado a questão de
> >> serialização/deserializaçào para integração, como é feito o controle de
> >> transação/validação e etc...
> > No início da thread eu linkei para um artigo que explica como
> > validações são feitas na Camada de Negócios (
> http://fragmental.tw/2009/08/21/ubiquitous-language-tiny-types-and-re... > > ). Na Camada de Apresentação ele depende da aplicação, geralmente
> > JavaScript para web e Specifications para clientes desktop. A
> > integração entre partes do mesmo sistema é feita via REST (completo,
> > incluindo HATEOAS), com outros sistemas depende do que este faz
> > disponível. Não sei exatamente o que você quer dizer com "controle de
> > transação" mas no geral uma transação (do NHibernate, não
> > necessariamente do banco) é aberta no início do Request e fechada no
> > final.
> > Todos os sistemas utilizam Domain Model e Domain-Drivel Design,
> > NHibernate e ASP.Net MVC. Alguns utilizam WPF e Silverlight.
> Oi Phillip, > Sim, e como das outras vezes, nada pessoal mas exemplos teóricos, artigos, > patterns, aplicações conceituais e etc. não adiantam. Como falei, é tudo > muito bonito e legal na teoria, mas quero ver como (e se) os problemas > práticos foram resolvidos em aplicações reais, médias ou grandes, em > produção.
> Alexandre, não estou te entendendo. Nenhuma das aplicações que citei
> aqui são teóricas, em todas eu estou falando de exemplo reais em
> produção.
> 2009/10/18 Alexandre Valente <alexandre.g.vale...@gmail.com>:
> > Oi Phillip,
> > Sim, e como das outras vezes, nada pessoal mas exemplos teóricos,
> artigos,
> > patterns, aplicações conceituais e etc. não adiantam. Como falei, é tudo
> > muito bonito e legal na teoria, mas quero ver como (e se) os problemas
> > práticos foram resolvidos em aplicações reais, médias ou grandes, em
> > produção.
Ops, cortou.
O link abaixo aponta para um artigo que fala de um aspecto de uma aplicação,
que pode até não ser conceitual (embora pareça) mas que com certeza nào é
usada por centanas de usuários simultaneos. E nem fala da arquitetura da
aplicação, somente de um pequeno aspecto.
Se vc quiser fazer algo por aqui, sugiro começar na linha que o André Dias
uma vez pediu. Descreva a aplicação, diga qual é o tipo e por quantas
pessoas é usada... Aí fale da linha geral da aplicação que com certeza irão
aparecer muitas perguntas...
> Alexandre, não estou te entendendo. Nenhuma das aplicações que citei
> aqui são teóricas, em todas eu estou falando de exemplo reais em
> produção.
> 2009/10/18 Alexandre Valente <alexandre.g.vale...@gmail.com>:
> > Oi Phillip,
> > Sim, e como das outras vezes, nada pessoal mas exemplos teóricos,
> artigos,
> > patterns, aplicações conceituais e etc. não adiantam. Como falei, é tudo
> > muito bonito e legal na teoria, mas quero ver como (e se) os problemas
> > práticos foram resolvidos em aplicações reais, médias ou grandes, em
> > produção.
> O link abaixo aponta para um artigo que fala de um aspecto de uma aplicação, > que pode até não ser conceitual (embora pareça) mas que com certeza nào é > usada por centanas de usuários simultaneos. E nem fala da arquitetura da > aplicação, somente de um pequeno aspecto. > Se vc quiser fazer algo por aqui, sugiro começar na linha que o André Dias > uma vez pediu. Descreva a aplicação, diga qual é o tipo e por quantas > pessoas é usada... Aí fale da linha geral da aplicação que com certeza irão > aparecer muitas perguntas...
Desculpe mas você está errado. E se procurar nos arquivos da lista vai ver emails onde eu já expliquei este sistema em específico, como por exemplo num email que te mandei há agum tempo:
> Nos últimos dois anos eu não lembro de ter visto nenhum sistema que > não usasse exceções para quebras de contrato. Estou falando de serviço > de cotação online para seguradoras, internet banking, websites de alto > volume e, mais recentemente, o sistema de venda de tickets utilizado > praticamente em todos os eventos esportivos e na maioria dos shows de > médio e grande porte por aqui.
> A aplicação de tickets não teve > probemas em atingir o objetivo de carga (que basicmente era a venda de > 80 mil tickets em 10 minutos com apenas 4 servidores), e para aumentar > a capacidade a arquitetura prevê escalabilidade horizontal -como > praticamente todas as grandes aplicações de Internet de grande porte. > Todas fortemente baseadas em contratos e onde a Camada de Apresentação > faz o parsing dos valores do usuário, a partir daí qualquer quebra de > contrato é uma exceção, devidamente tratada e logada.
Creio que os exemplos já foram dados, estou disposto a clarificar e expandir os pontos mas, sinceramente, prefiro ter que repetir tudo novamente a cada thread.
Oi Phillip,
Tentei mas não consegui encontrar. Esta aplicação de tickets a que vc se
refere é esta do artigo que vc colocou o link? Qual o propósito dela,
controlar billable hours? Como isto pode isto ter 80 mil tickets em 10
minutos?
Desculpe se estou sendo chato, mas a impressão é que vc não quer colocar
usar um exemplo de uma aplicação real (talvez por restrições legais?) para
que possamos dissecar e entender quais as decisões tomadas e como os
problemas de um modelo rico foram resolvidos. Se for isto, sem probelmas, é
só falar... :-).
> 2009/10/18 Alexandre Valente <alexandre.g.vale...@gmail.com>:
> > O link abaixo aponta para um artigo que fala de um aspecto de uma
> aplicação,
> > que pode até não ser conceitual (embora pareça) mas que com certeza nào é
> > usada por centanas de usuários simultaneos. E nem fala da arquitetura da
> > aplicação, somente de um pequeno aspecto.
> > Se vc quiser fazer algo por aqui, sugiro começar na linha que o André
> Dias
> > uma vez pediu. Descreva a aplicação, diga qual é o tipo e por quantas
> > pessoas é usada... Aí fale da linha geral da aplicação que com certeza
> irão
> > aparecer muitas perguntas...
> Desculpe mas você está errado. E se procurar nos arquivos da lista vai
> ver emails onde eu já expliquei este sistema em específico, como por
> exemplo num email que te mandei há agum tempo:
> 2009/10/4 Phillip Calçado <pcalc...@gmail.com>:
> > Nos últimos dois anos eu não lembro de ter visto nenhum sistema que
> > não usasse exceções para quebras de contrato. Estou falando de serviço
> > de cotação online para seguradoras, internet banking, websites de alto
> > volume e, mais recentemente, o sistema de venda de tickets utilizado
> > praticamente em todos os eventos esportivos e na maioria dos shows de
> > médio e grande porte por aqui.
> > A aplicação de tickets não teve
> > probemas em atingir o objetivo de carga (que basicmente era a venda de
> > 80 mil tickets em 10 minutos com apenas 4 servidores), e para aumentar
> > a capacidade a arquitetura prevê escalabilidade horizontal -como
> > praticamente todas as grandes aplicações de Internet de grande porte.
> > Todas fortemente baseadas em contratos e onde a Camada de Apresentação
> > faz o parsing dos valores do usuário, a partir daí qualquer quebra de
> > contrato é uma exceção, devidamente tratada e logada.
> Creio que os exemplos já foram dados, estou disposto a clarificar e
> expandir os pontos mas, sinceramente, prefiro ter que repetir tudo
> novamente a cada thread.
Alexanre, a aplicação de ticket que o phillip citou é uma aplicação pra
venda de ingressos online.
Essa do blog, é uma aplicação de controle de horas.
Ele quis dizer, pelo que eu entendi, que em ambos estes casos as aplicações
são de grande uso(no caso da app de tickets, ele comentou que venderam mais
de 80k tickets em 10min., ou seja, alta performance e disponibilidade) e
foram feitas com modelo rico.
> Oi Phillip,
> Tentei mas não consegui encontrar. Esta aplicação de tickets a que vc se
> refere é esta do artigo que vc colocou o link? Qual o propósito dela,
> controlar billable hours? Como isto pode isto ter 80 mil tickets em 10
> minutos?
> Desculpe se estou sendo chato, mas a impressão é que vc não quer colocar
> usar um exemplo de uma aplicação real (talvez por restrições legais?) para
> que possamos dissecar e entender quais as decisões tomadas e como os
> problemas de um modelo rico foram resolvidos. Se for isto, sem probelmas, é
> só falar... :-).
>> 2009/10/18 Alexandre Valente <alexandre.g.vale...@gmail.com>:
>> > O link abaixo aponta para um artigo que fala de um aspecto de uma
>> aplicação,
>> > que pode até não ser conceitual (embora pareça) mas que com certeza nào
>> é
>> > usada por centanas de usuários simultaneos. E nem fala da arquitetura da
>> > aplicação, somente de um pequeno aspecto.
>> > Se vc quiser fazer algo por aqui, sugiro começar na linha que o André
>> Dias
>> > uma vez pediu. Descreva a aplicação, diga qual é o tipo e por quantas
>> > pessoas é usada... Aí fale da linha geral da aplicação que com certeza
>> irão
>> > aparecer muitas perguntas...
>> Desculpe mas você está errado. E se procurar nos arquivos da lista vai
>> ver emails onde eu já expliquei este sistema em específico, como por
>> exemplo num email que te mandei há agum tempo:
>> 2009/10/4 Phillip Calçado <pcalc...@gmail.com>:
>> > Nos últimos dois anos eu não lembro de ter visto nenhum sistema que
>> > não usasse exceções para quebras de contrato. Estou falando de serviço
>> > de cotação online para seguradoras, internet banking, websites de alto
>> > volume e, mais recentemente, o sistema de venda de tickets utilizado
>> > praticamente em todos os eventos esportivos e na maioria dos shows de
>> > médio e grande porte por aqui.
>> > A aplicação de tickets não teve
>> > probemas em atingir o objetivo de carga (que basicmente era a venda de
>> > 80 mil tickets em 10 minutos com apenas 4 servidores), e para aumentar
>> > a capacidade a arquitetura prevê escalabilidade horizontal -como
>> > praticamente todas as grandes aplicações de Internet de grande porte.
>> > Todas fortemente baseadas em contratos e onde a Camada de Apresentação
>> > faz o parsing dos valores do usuário, a partir daí qualquer quebra de
>> > contrato é uma exceção, devidamente tratada e logada.
>> Creio que os exemplos já foram dados, estou disposto a clarificar e
>> expandir os pontos mas, sinceramente, prefiro ter que repetir tudo
>> novamente a cada thread.
Ok, vamos escolher uma delas entao como caso de estudo. A de venda de
ingressos online me parece muito interessante.
Imagino que ela use um modelo rico de domínio. Assim, perguntas básicas:
Qual a arquitetura (camadas, etc)? Usa NH? AR? Qual banco de dados? E
apresentação, usa MVC? Isto pra começar, a partir destas respostas, com
certeza vou ter mais muitas questões (que acho que vão ser a de muitas
pessoas da lista tbm).
Se vc (e quem mais conhecer esta aplicação bem) estiver disposto, sugiro
abrir uma thread pra falarmos dela. Tenho certeza que vai ser muito
construtivo! :-)
> Alexanre, a aplicação de ticket que o phillip citou é uma aplicação pra
> venda de ingressos online.
> Essa do blog, é uma aplicação de controle de horas.
> Ele quis dizer, pelo que eu entendi, que em ambos estes casos as aplicações
> são de grande uso(no caso da app de tickets, ele comentou que venderam mais
> de 80k tickets em 10min., ou seja, alta performance e disponibilidade) e
> foram feitas com modelo rico.
>> Oi Phillip,
>> Tentei mas não consegui encontrar. Esta aplicação de tickets a que vc se
>> refere é esta do artigo que vc colocou o link? Qual o propósito dela,
>> controlar billable hours? Como isto pode isto ter 80 mil tickets em 10
>> minutos?
>> Desculpe se estou sendo chato, mas a impressão é que vc não quer colocar
>> usar um exemplo de uma aplicação real (talvez por restrições legais?) para
>> que possamos dissecar e entender quais as decisões tomadas e como os
>> problemas de um modelo rico foram resolvidos. Se for isto, sem probelmas, é
>> só falar... :-).
>>> 2009/10/18 Alexandre Valente <alexandre.g.vale...@gmail.com>:
>>> > O link abaixo aponta para um artigo que fala de um aspecto de uma
>>> aplicação,
>>> > que pode até não ser conceitual (embora pareça) mas que com certeza nào
>>> é
>>> > usada por centanas de usuários simultaneos. E nem fala da arquitetura
>>> da
>>> > aplicação, somente de um pequeno aspecto.
>>> > Se vc quiser fazer algo por aqui, sugiro começar na linha que o André
>>> Dias
>>> > uma vez pediu. Descreva a aplicação, diga qual é o tipo e por quantas
>>> > pessoas é usada... Aí fale da linha geral da aplicação que com certeza
>>> irão
>>> > aparecer muitas perguntas...
>>> Desculpe mas você está errado. E se procurar nos arquivos da lista vai
>>> ver emails onde eu já expliquei este sistema em específico, como por
>>> exemplo num email que te mandei há agum tempo:
>>> 2009/10/4 Phillip Calçado <pcalc...@gmail.com>:
>>> > Nos últimos dois anos eu não lembro de ter visto nenhum sistema que
>>> > não usasse exceções para quebras de contrato. Estou falando de serviço
>>> > de cotação online para seguradoras, internet banking, websites de alto
>>> > volume e, mais recentemente, o sistema de venda de tickets utilizado
>>> > praticamente em todos os eventos esportivos e na maioria dos shows de
>>> > médio e grande porte por aqui.
>>> > A aplicação de tickets não teve
>>> > probemas em atingir o objetivo de carga (que basicmente era a venda de
>>> > 80 mil tickets em 10 minutos com apenas 4 servidores), e para aumentar
>>> > a capacidade a arquitetura prevê escalabilidade horizontal -como
>>> > praticamente todas as grandes aplicações de Internet de grande porte.
>>> > Todas fortemente baseadas em contratos e onde a Camada de Apresentação
>>> > faz o parsing dos valores do usuário, a partir daí qualquer quebra de
>>> > contrato é uma exceção, devidamente tratada e logada.
>>> Creio que os exemplos já foram dados, estou disposto a clarificar e
>>> expandir os pontos mas, sinceramente, prefiro ter que repetir tudo
>>> novamente a cada thread.
> Ok, vamos escolher uma delas entao como caso de estudo. A de venda de > ingressos online me parece muito interessante.
> Imagino que ela use um modelo rico de domínio. Assim, perguntas > básicas: Qual a arquitetura (camadas, etc)? Usa NH? AR? Qual banco de > dados? E apresentação, usa MVC? Isto pra começar, a partir destas > respostas, com certeza vou ter mais muitas questões (que acho que vão > ser a de muitas pessoas da lista tbm).
> Se vc (e quem mais conhecer esta aplicação bem) estiver disposto, > sugiro abrir uma thread pra falarmos dela. Tenho certeza que vai ser > muito construtivo! :-)
> Ok, vamos escolher uma delas entao como caso de estudo. A de venda de
> ingressos online me parece muito interessante.
> Imagino que ela use um modelo rico de domínio. Assim, perguntas básicas:
> Qual a arquitetura (camadas, etc)? Usa NH? AR? Qual banco de dados? E
> apresentação, usa MVC? Isto pra começar, a partir destas respostas, com
> certeza vou ter mais muitas questões (que acho que vão ser a de muitas
> pessoas da lista tbm).
> Se vc (e quem mais conhecer esta aplicação bem) estiver disposto, sugiro
> abrir uma thread pra falarmos dela. Tenho certeza que vai ser muito
> construtivo! :-)
> Alexanre, a aplicação de ticket que o phillip citou é uma aplicação pra
>> venda de ingressos online.
>> Essa do blog, é uma aplicação de controle de horas.
>> Ele quis dizer, pelo que eu entendi, que em ambos estes casos as
>> aplicações são de grande uso(no caso da app de tickets, ele comentou que
>> venderam mais de 80k tickets em 10min., ou seja, alta performance e
>> disponibilidade) e foram feitas com modelo rico.
>>> Oi Phillip,
>>> Tentei mas não consegui encontrar. Esta aplicação de tickets a que vc se
>>> refere é esta do artigo que vc colocou o link? Qual o propósito dela,
>>> controlar billable hours? Como isto pode isto ter 80 mil tickets em 10
>>> minutos?
>>> Desculpe se estou sendo chato, mas a impressão é que vc não quer colocar
>>> usar um exemplo de uma aplicação real (talvez por restrições legais?) para
>>> que possamos dissecar e entender quais as decisões tomadas e como os
>>> problemas de um modelo rico foram resolvidos. Se for isto, sem probelmas, é
>>> só falar... :-).
>>>> 2009/10/18 Alexandre Valente <alexandre.g.vale...@gmail.com>:
>>>> > O link abaixo aponta para um artigo que fala de um aspecto de uma
>>>> aplicação,
>>>> > que pode até não ser conceitual (embora pareça) mas que com certeza
>>>> nào é
>>>> > usada por centanas de usuários simultaneos. E nem fala da arquitetura
>>>> da
>>>> > aplicação, somente de um pequeno aspecto.
>>>> > Se vc quiser fazer algo por aqui, sugiro começar na linha que o André
>>>> Dias
>>>> > uma vez pediu. Descreva a aplicação, diga qual é o tipo e por quantas
>>>> > pessoas é usada... Aí fale da linha geral da aplicação que com certeza
>>>> irão
>>>> > aparecer muitas perguntas...
>>>> Desculpe mas você está errado. E se procurar nos arquivos da lista vai
>>>> ver emails onde eu já expliquei este sistema em específico, como por
>>>> exemplo num email que te mandei há agum tempo:
>>>> 2009/10/4 Phillip Calçado <pcalc...@gmail.com>:
>>>> > Nos últimos dois anos eu não lembro de ter visto nenhum sistema que
>>>> > não usasse exceções para quebras de contrato. Estou falando de serviço
>>>> > de cotação online para seguradoras, internet banking, websites de alto
>>>> > volume e, mais recentemente, o sistema de venda de tickets utilizado
>>>> > praticamente em todos os eventos esportivos e na maioria dos shows de
>>>> > médio e grande porte por aqui.
>>>> > A aplicação de tickets não teve
>>>> > probemas em atingir o objetivo de carga (que basicmente era a venda de
>>>> > 80 mil tickets em 10 minutos com apenas 4 servidores), e para aumentar
>>>> > a capacidade a arquitetura prevê escalabilidade horizontal -como
>>>> > praticamente todas as grandes aplicações de Internet de grande porte.
>>>> > Todas fortemente baseadas em contratos e onde a Camada de Apresentação
>>>> > faz o parsing dos valores do usuário, a partir daí qualquer quebra de
>>>> > contrato é uma exceção, devidamente tratada e logada.
>>>> Creio que os exemplos já foram dados, estou disposto a clarificar e
>>>> expandir os pontos mas, sinceramente, prefiro ter que repetir tudo
>>>> novamente a cada thread.
>> Ok, vamos escolher uma delas entao como caso de estudo. A de venda de
>> ingressos online me parece muito interessante.
>> Imagino que ela use um modelo rico de domínio. Assim, perguntas básicas:
>> Qual a arquitetura (camadas, etc)? Usa NH? AR? Qual banco de dados? E
>> apresentação, usa MVC? Isto pra começar, a partir destas respostas, com
>> certeza vou ter mais muitas questões (que acho que vão ser a de muitas
>> pessoas da lista tbm).
>> Se vc (e quem mais conhecer esta aplicação bem) estiver disposto, sugiro
>> abrir uma thread pra falarmos dela. Tenho certeza que vai ser muito
>> construtivo! :-)
>> Alexanre, a aplicação de ticket que o phillip citou é uma aplicação pra
>>> venda de ingressos online.
>>> Essa do blog, é uma aplicação de controle de horas.
>>> Ele quis dizer, pelo que eu entendi, que em ambos estes casos as
>>> aplicações são de grande uso(no caso da app de tickets, ele comentou que
>>> venderam mais de 80k tickets em 10min., ou seja, alta performance e
>>> disponibilidade) e foram feitas com modelo rico.
>>>> Oi Phillip,
>>>> Tentei mas não consegui encontrar. Esta aplicação de tickets a que vc se
>>>> refere é esta do artigo que vc colocou o link? Qual o propósito dela,
>>>> controlar billable hours? Como isto pode isto ter 80 mil tickets em 10
>>>> minutos?
>>>> Desculpe se estou sendo chato, mas a impressão é que vc não quer colocar
>>>> usar um exemplo de uma aplicação real (talvez por restrições legais?) para
>>>> que possamos dissecar e entender quais as decisões tomadas e como os
>>>> problemas de um modelo rico foram resolvidos. Se for isto, sem probelmas, é
>>>> só falar... :-).
>>>>> 2009/10/18 Alexandre Valente <alexandre.g.vale...@gmail.com>:
>>>>> > O link abaixo aponta para um artigo que fala de um aspecto de uma
>>>>> aplicação,
>>>>> > que pode até não ser conceitual (embora pareça) mas que com certeza
>>>>> nào é
>>>>> > usada por centanas de usuários simultaneos. E nem fala da arquitetura
>>>>> da
>>>>> > aplicação, somente de um pequeno aspecto.
>>>>> > Se vc quiser fazer algo por aqui, sugiro começar na linha que o André
>>>>> Dias
>>>>> > uma vez pediu. Descreva a aplicação, diga qual é o tipo e por quantas
>>>>> > pessoas é usada... Aí fale da linha geral da aplicação que com
>>>>> certeza irão
>>>>> > aparecer muitas perguntas...
>>>>> Desculpe mas você está errado. E se procurar nos arquivos da lista vai
>>>>> ver emails onde eu já expliquei este sistema em específico, como por
>>>>> exemplo num email que te mandei há agum tempo:
>>>>> 2009/10/4 Phillip Calçado <pcalc...@gmail.com>:
>>>>> > Nos últimos dois anos eu não lembro de ter visto nenhum sistema que
>>>>> > não usasse exceções para quebras de contrato. Estou falando de
>>>>> serviço
>>>>> > de cotação online para seguradoras, internet banking, websites de
>>>>> alto
>>>>> > volume e, mais recentemente, o sistema de venda de tickets utilizado
>>>>> > praticamente em todos os eventos esportivos e na maioria dos shows de
>>>>> > médio e grande porte por aqui.
>>>>> > A aplicação de tickets não teve
>>>>> > probemas em atingir o objetivo de carga (que basicmente era a venda
>>>>> de
>>>>> > 80 mil tickets em 10 minutos com apenas 4 servidores), e para
>>>>> aumentar
>>>>> > a capacidade a arquitetura prevê escalabilidade horizontal -como
>>>>> > praticamente todas as grandes aplicações de Internet de grande porte.
>>>>> > Todas fortemente baseadas em contratos e onde a Camada de
>>>>> Apresentação
>>>>> > faz o parsing dos valores do usuário, a partir daí qualquer quebra de
>>>>> > contrato é uma exceção, devidamente tratada e logada.
>>>>> Creio que os exemplos já foram dados, estou disposto a clarificar e
>>>>> expandir os pontos mas, sinceramente, prefiro ter que repetir tudo
>>>>> novamente a cada thread.
Cheguei tarde à discussão e compartilho do mesmo sentimento.
From: dotnetarchitects@googlegroups.com
[mailto:dotnetarchitects@googlegroups.com] On Behalf Of Alexandre Valente
Sent: sábado, 17 de outubro de 2009 15:59
To: dotnetarchitects@googlegroups.com
Subject: [dotnetarchitects] Re: Domain Models, Anemic Domain Models and
Transaction Scripts
Realmente é impressionante como este assunto vai e volta nesta lista e
aparentemente em toda a comunidade de desenvolvedores do mundo... :-).
Pra mim este assunto é fascinante. O agumento contra anemic models é sólido,
mas somente à primeira vista. Como o próprio artigo e o Fowler citam, a
longo prazo o que temos é objetos complexos, cheios de regras que ninguem
sabe onde e quando usar e algo que era pra ser um POCO se transforma em um
mini-monstrinho... (e o próprio autor se coloca ele como inexperiente em
dominios ricos.... quero ver o blog dele daqui a 2 ou 3 anos se permanece o
mesmo! :-))
Apesar de vários defenderem nesta lista o uso de modelos ricos, até hoje eu
não vi um único exemplo de uma aplicação de médio ou grande porte (.net,
claro), que esteja em produção, e que faça uso de domínio rico de maneira
consistente. Todos os exemplos são academicos, de pequenos sistemas ou
simplesmente provas de conceito.
Esta questão dos objetos se tornarem inchados, da dificuldade em fazer algo
prático para controlar os aspectos do serviços (transação, log etc) e o
própria localização das regras (qual objeto faz o que) pra mim torna um
modelo rico sempre um pesadelo de manutenção.
From: dotnetarchitects@googlegroups.com
[mailto:dotnetarchitects@googlegroups.com] On Behalf Of Eduardo Miranda
Sent: domingo, 18 de outubro de 2009 14:43
To: dotnetarchitects@googlegroups.com
Subject: [dotnetarchitects] Re: Domain Models, Anemic Domain Models and
Transaction Scripts
Concordo que este tipo de discussão será bem mais proveitosa.
Ok, vamos escolher uma delas entao como caso de estudo. A de venda de
ingressos online me parece muito interessante.
Imagino que ela use um modelo rico de domínio. Assim, perguntas básicas:
Qual a arquitetura (camadas, etc)? Usa NH? AR? Qual banco de dados? E
apresentação, usa MVC? Isto pra começar, a partir destas respostas, com
certeza vou ter mais muitas questões (que acho que vão ser a de muitas
pessoas da lista tbm).
Se vc (e quem mais conhecer esta aplicação bem) estiver disposto, sugiro
abrir uma thread pra falarmos dela. Tenho certeza que vai ser muito
construtivo! :-)
Alexanre, a aplicação de ticket que o phillip citou é uma aplicação pra
venda de ingressos online.
Essa do blog, é uma aplicação de controle de horas.
Ele quis dizer, pelo que eu entendi, que em ambos estes casos as aplicações
são de grande uso(no caso da app de tickets, ele comentou que venderam mais
de 80k tickets em 10min., ou seja, alta performance e disponibilidade) e
foram feitas com modelo rico.
Tentei mas não consegui encontrar. Esta aplicação de tickets a que vc se
refere é esta do artigo que vc colocou o link? Qual o propósito dela,
controlar billable hours? Como isto pode isto ter 80 mil tickets em 10
minutos?
Desculpe se estou sendo chato, mas a impressão é que vc não quer colocar
usar um exemplo de uma aplicação real (talvez por restrições legais?) para
que possamos dissecar e entender quais as decisões tomadas e como os
problemas de um modelo rico foram resolvidos. Se for isto, sem probelmas, é
só falar... :-).
> O link abaixo aponta para um artigo que fala de um aspecto de uma
aplicação,
> que pode até não ser conceitual (embora pareça) mas que com certeza nào é
> usada por centanas de usuários simultaneos. E nem fala da arquitetura da
> aplicação, somente de um pequeno aspecto.
> Se vc quiser fazer algo por aqui, sugiro começar na linha que o André Dias
> uma vez pediu. Descreva a aplicação, diga qual é o tipo e por quantas
> pessoas é usada... Aí fale da linha geral da aplicação que com certeza
irão
> aparecer muitas perguntas...
Desculpe mas você está errado. E se procurar nos arquivos da lista vai
ver emails onde eu já expliquei este sistema em específico, como por
exemplo num email que te mandei há agum tempo:
> Nos últimos dois anos eu não lembro de ter visto nenhum sistema que
> não usasse exceções para quebras de contrato. Estou falando de serviço
> de cotação online para seguradoras, internet banking, websites de alto
> volume e, mais recentemente, o sistema de venda de tickets utilizado
> praticamente em todos os eventos esportivos e na maioria dos shows de
> médio e grande porte por aqui.
> A aplicação de tickets não teve
> probemas em atingir o objetivo de carga (que basicmente era a venda de
> 80 mil tickets em 10 minutos com apenas 4 servidores), e para aumentar
> a capacidade a arquitetura prevê escalabilidade horizontal -como
> praticamente todas as grandes aplicações de Internet de grande porte.
> Todas fortemente baseadas em contratos e onde a Camada de Apresentação
> faz o parsing dos valores do usuário, a partir daí qualquer quebra de
> contrato é uma exceção, devidamente tratada e logada.
Creio que os exemplos já foram dados, estou disposto a clarificar e
expandir os pontos mas, sinceramente, prefiro ter que repetir tudo
novamente a cada thread.
|
