Concordo… mas existem pessoas com conhecimento em DDD (por exemplo) e que não são “tão a favor” desta abordagem por acharem que em nem todos os casos o DDD é válido… não falo de projetos simples ou complexos… acho que DDD não depende de complexidade… mas existem projetos que o DDD só enrola a maneira mais simples de fazer… Vcs (MJ) são formadores de opinião, isso é fato! Muitos iniciantes são guiados pelas matérias que vcs publicam. E eles precisam saber que o DDD não é o último biscoito do pacote!
Rodrigo, logicamente que vou escrever mais um artigo com DDD Patterns a pedido de vocês, apesar do Shoes já ter escrito sobre isso. Talvez faça com Spring e Hibernate (uma infra mais leve que o Seam para simplificar). Vou conversar com o nosso amigo Guerra a respeito para o artigo de Julho (pena que vai demorar). 
De qualquer forma, o artigo desta edição não é de forma alguma “blá blá blá filosófico” como colocaram aqui. :? Conceituei Domain Model, dei exemplos práticos de erros na Ubiquitous Language, falei sobre mudanças que podem ocorrer no processo de desenvolvimento e até escreví sobre o COMO, através da apresentação do estudo de caso “Santa Paola”, em complemento ao código. E de fato, para a DDD esse é o mais importante, por mais paixão/dúvidas que vocês tenham pelo lado bits-bytes. 
Que tal publicar em um blog ou algo do gênero. Pode fazer isto em poucos dias e com pouco trabalho
Se não nos apegarmos aos significados e aos conceitos e às suas representações reais seria uma bagunça inumerável e ninguem se entenderia.
Se eu apresentar isto
object.method(otherobject)
e lhe disser que é uma estrutura de repetição vc não vai acreditar em mim. Vc esperaria algo como
while (condition){
//do something
}Mas se eu escrever isto:
component.accept(visitor)
Tlv vc aceite, porque os nomes foram escolhidos a dedo. E se vc tiver o mesmo conceito que eu, e estiver usando a mema nomenclatura é simples de aceitar.
Mas se isso não é suficiente (não será para 80% das pessoas) vc tem que explicar o que está em causa ali. Aquilo é uma das partes do padrão Visitor.
E agora sim, poderemos discutir se o padrão visitor implementa ou não uma estrutura de repetição.
E não importa o que mais ninguem disse sobre essa afirmação.
Não é aceitável que se aceite que a informática é baseada em crenças, opiniões, hypes, etc… tecnologia pode até ser assim, mas ideias não são tecnologia. Ideias são ideias. As aceitamos ou rejeitamos. As desenvolvemos.
Não interessa quantos hypes ha por ai, todos dizem a mesma coisa. Todos fogem do mecanismo rigido em que o software é feito como um prédio ou uma ponte. Acho que é obvio neste momento que software não é engenharia civil. Então não vamos bater mais em teclas de pianos antigos. Queremos dar um passo em frente.
Se realmente DDD não tem nada a ver com patterns não escreva mais sobre isso. Não se deixe cair na tentação do que o publico quer. Mas se afinal os conceitos não são para ser levados à risca e é aceitável vc escrever um artigo sobre os patterns DDD não vejo porque razão não é aceitável dizer que os padrões fazem parte da DDD.
São um corolário das ideias vinculadas por um modelo e linguagem omnipresente.
Se não quiser dar esse passo a mais , tudo bem. Continue ligado à rigidez dos livros , autores e citações que conhece a abandone a ideia de que os patterns têm alguma coisa a ver com DDD. Isto não é uma religião. Ninguem o força a aceitar as ideias com base na fé.
O que não lhe é permitido é ter dois pesos e duas medidas. Ou bem que se é rigido e se aceita que DDD não tem nada a ver com patterns, e portanto não presta nenhum guia para construir código( embora peça que o modelo de dominio seja traduzido em codigo. Isso é uma antitese. É mais ou menos como o médico lhe dizer que tem que cuidar da saude, mas não lhe explicar como) Ou bem que se aceita que ha espaço para manobra e não ha uma rigidez absolutas das teorias e filosofias associadas ao DDD. Caso em que, podemos muito bem evoluir o DDD para a associação de padrões e codigo e dizer que o padrões fazem parte sim da DDD. ( supondo que não faziam antes)
Como eu acho que ha espaço para evoluir e como não me apego a livros (biblias?) e citações eu prefiro associar os padrões com a DDD. (Crufiquem-me, mas eu gosto de explicar como a pessoa pode tratar da saude, em vez de apenas dizer que tem que a tratar. )
Então a conclusão é a seguinte:
A)Se a teoria da DDD inclue os padrões no seu nucleo, temos que entender como eles entregam a promessa de construir um modelo de dominio com codigo.
B)Se a teoria da DDD não inclui os padrões no seu nucleo , ela é inutil pois não explicar como entregar a promessa de construir um modelo de dominio com codigo.
Em qualquer dos casos o artigo está incompleto sem explicar como a promessa de construir um modelo de dominio com codigo é alcançada. Com ou sem falar em padrões.
Apresentar codigo pronto não é igual a explicar. É como dizer que as piramides são possiveis e colocar um foto delas. Isso não explicar como elas foram construidas.
A minha resalva ao artigo era apenas essa: gostaria de ler uma explicação de como construir um modelo de dominio com codigo.
Mas como vc mesmo falou, uma só explicação não é suficiente. Uma só visão de um so caso de exemplo, não é suficiente. É verdade. Concordo com vc, é melhor não ter nenhum. E neste caso entendo porque o artigo termina onde termina e não penso que ele está incompleto.
Obrigado pelo dialogo.
P.S.
Mas mesmo assim eu vou continuar procurar como se traduz o modelo de dominio em codigo.
[quote=sergiotaborda]A minha resalva ao artigo era apenas essa: gostaria de ler uma explicação de como construir um modelo de dominio com codigo.
Mas como vc mesmo falou, uma só explicação não é suficiente. Uma só visão de um so caso de exemplo, não é suficiente. É verdade. Concordo com vc, é melhor não ter nenhum. E neste caso entendo porque o artigo termina onde termina e não penso que ele está incompleto.
P.S.
Mas mesmo assim eu vou continuar procurar como se traduz o modelo de dominio em codigo. [/quote]
Vc não é o unico, eu também procuro e parece que outros tb estao procurando
[quote=pcalcado]Iniciante ou não, o ponto é: como ter o domínio modelado como software numa relação próxima de 1-para-1 hoje em dia? Como implementar a linguagem de domínio?
Eu não li o livro que você indicou mas duvido muito que ele responda perguntas como: o que diabos eu faço com a persistência? De onde eu tiro os objetos se não do banco de dados? Se eu tiro do banco de dados, como fica meu domínio?[/quote
Sergio,
DDD é algo mais amplo, compreende a UBIQUITOUS LANGUAGE e MODEL-DRIVEN-DESIGN.
Os padroes pertencem ao segundo e o artigo da revista focou no primeiro.
Concordo… mas existem pessoas com conhecimento em DDD (por exemplo) e que não são “tão a favor” desta abordagem por acharem que em nem todos os casos o DDD é válido… não falo de projetos simples ou complexos… acho que DDD não depende de complexidade… mas existem projetos que o DDD só enrola a maneira mais simples de fazer… Vcs (MJ) são formadores de opinião, isso é fato! Muitos iniciantes são guiados pelas matérias que vcs publicam. E eles precisam saber que o DDD não é o último biscoito do pacote![/quote]
Normalmente, quando a pessoa não utiliza alguma coisa, normalmente não o faz porque prefere utilizar uma outra abordagem. Se você conhecer alguém que queira escrever um artigo sobre alguma outra técnica que julga ser melhor, mostrando os problemas e as deficiências do DDD, por favor, peça para essa pessoa entrar em contato comigo. Porém, não me agrada muito a idéia de um artigo que só critica uma abordagem, sem mostrar um forma melhor de fazer!
Quer apostar? :twisted:
Quer apostar? :twisted: [/quote]
Se o livro em questão é o OO em 21 dias, é bem provavel que você vai perder a aposta! 
Nem de persistência ele fala! rsrs
Rodrigo, não leve a mal minha inquietação. Não sei se posso concordar com essa sua afirmação. Você está dizendo para não seguirmos algumas coisas ao pé da letra, tudo bem. Mas em muitas discussões que rolaram aqui no GUJ recomendavam que o repositório deveria parecer mais com uma collection, utilizando por exemplo add ao invés de save.
IMHO, ao usar save ao invés de add seu repositório fica meio ‘data base driven’. Pra alguém falar que isso ai é um DAO não custa muito. Daí a importância de que algumas coisas seriam melhores se fossem ao pé da letra.
Que fique bem claro que não estou dizendo que seu repositório é um DAO. Entendi sua explicação. Nem quero que esta discussão vire DAO x Repository. Sairia completamente do foco. Resumidamente, IMO usar repository.save ao invés de repository.add afeta a qualidade da comunicação e isso me faz questionar se devemos ou não ser rigidos na hora de explicar e ensinar algum novo conceito.
Quer apostar? :twisted: [/quote]
Olá Alessandro.
As palavras que vc citou acima não são minhas, estas pertencem ao Phillip Calçado argumentando com o Thiago Senna.
Creio que houve uma pequena confusão, e de fato o livro não responde as perguntas.
Mandei mal agora … eles falavam do OO em 21 dias e eu pensei que foi um post seu se referindo ao Domain-Driven Design book.
:?
(Ronildo, você deveria ter aceitado a aposta… e só depois esclarecido, hehe)
Vão ter quantas partes esse resumo? Alguem sabe?
rsrsrsrs na próxima eu não irei perdoar
Voltando ao assunto, acredito que vc tenha lido o livro do DDD, portanto qual a abordagem do livro para responder as peguntas: O que diabos eu faço com a persistência? De onde eu tiro os objetos se não do banco de dados? Se eu tiro do banco de dados, como fica meu domínio?
Sei que o pattern repository ajuda, mas isto é suficiente ?
Sergio, nem sempre padrões são explícitos. A API de InputStreams do Java é baseada em Decorators, nem por isso há menção clara a respeito disso, senão, chamaria BufferedOutputStreamDecorator. Muito da API do Swing é baseada em Observers e nem por isso consta em qualquer lugar que tal padrão é utilizado. Padrões são só soluções comuns. Um Visitor não precisa estar necessariamente implementado dessa maneira e com esses nomes para ser um Visitor.
Concordo com alguns autores que defendem que padrões são mais importantes pelo aspecto didático. Na maioria das vezes trabalhamos gerenciando dependências de olho em coesão, acoplamento e complexidade. A partir do momento que você conhece bem e já aplica OO, você não pensa mais nos padrões. Eles se tornam naturais. O pensamento é “vou desacoplar isso” e não “vou usar o padrão Strategy” (eu mesmo costumo esquecer o nome dos padrões) :?
É exatamente isso! As aceitamos ou as rejeitamos. Aceitamos e rejeitamos baseados em quê? Em crença na maioria das vezes. Nós lemos os livros do Ambler, Fowler, Schwaber, Beck, GOF, Três Amigos por que? Basicamente porque acreditamos neles. Muitos deles dizem: “-Olha, minha técnica não é 100% garantida que funciona, depende de um monte de coisa”. Isso é uma ciência exata? Não. Se não é, muita intuição está em jogo. Na maioria das vezes seguimos as práticas simplesmente porque elas nos fazem sentido e já erramos anteriormente. Não temos certeza que elas funcionam, nunca trabalhamos em nenhum projeto com esses caras e nem sabemos se eles realmente tiveram sucesso na aplicação dessas técnicas. Como vc pode ver, a questão é complexa.
O software, como qualquer outro produto do meio criativo é uma idéia [não me lembro direito que autor falou isso].
Se eu não escrever o que o público quer, vou escrever sobre o quê? E outra, nenhum momento disse que os padrões DDD não são importantes. Eles são! Só que na minha visão, eles são fáceis na tecnologia atual se você parar com frescura e picuínhas. Essa rigidez conceitual que existe (ainda) na comunidade Java é exatamente o que fez muita gente engolir EJB goela abaixo sem se questionar muito (mais uma decisão baseada em crença para alguns: “-Se a Sun está dizendo que é assim, eles devem estar certos.” (não digo que isso está certo).
Não entendí o que vc quis dizer com isso.
Que momento eu disse que os patterns não são importantes? Escreví o artigo focado em Domain Model e Ubiquitous Language (o cerne da DDD), fiz o código baseado em Padrões que já discutimos aqui. E creio que o Value Object e o Repository estão claros. O código está sim refletindo o dominio. Aonde está a antitese? O que você está pedindo é outra coisa. Você quer saber o que passou pela minha cabeça quando o cliente solicitava as coisas e aloquei responsabilidades às classes. Bom, as figuras 5 e 6 mostram um pouco isso. As figuras 1 e 2 mostram o anti-pattern. Se você não gostou do artigo porque não foquei mais nisso, paciência.
Estamos fundamentados na alternativa A desde o começo. Os padrões são importantes, mas, Domain Model e Ubiquitous Language são mais. É possível aplicar DDD em sistemas que não são baseados em objetos. Nesse caso, os padrões não são aplicados, mas não deixa de ser DDD.
Mais uma vez. O código está lá. Os padrões estão lá. As figuras 5 e 6 estão lá. E mais, o artigo do Shoes citado também existe.
Ok. O artigo não foi perfeito nesse ponto. Mas, paciência. Fica para um próximo. Mais uma vez vou repetir. A parte técnica da DDD é fácil para a maioria dos sistemas. As tecnologias atuais ajudam muito. As pessoas tendem a complicar coisas que são simples. Compreender o real domínio da aplicação, estabelecer uma abstração de um domain model e fortalecer a ubiquitous language são mais difíceis.
[quote=Thiago Senna]
Rodrigo, não leve a mal minha inquietação. Não sei se posso concordar com essa sua afirmação. Você está dizendo para não seguirmos algumas coisas ao pé da letra, tudo bem. Mas em muitas discussões que rolaram aqui no GUJ recomendavam que o repositório deveria parecer mais com uma collection, utilizando por exemplo add ao invés de save.
IMHO, ao usar save ao invés de add seu repositório fica meio ‘data base driven’. Pra alguém falar que isso ai é um DAO não custa muito. Daí a importância de que algumas coisas seriam melhores se fossem ao pé da letra.
Que fique bem claro que não estou dizendo que seu repositório é um DAO. Entendi sua explicação. Nem quero que esta discussão vire DAO x Repository. Sairia completamente do foco. Resumidamente, IMO usar repository.save ao invés de repository.add afeta a qualidade da comunicação e isso me faz questionar se devemos ou não ser rigidos na hora de explicar e ensinar algum novo conceito.[/quote]
Thiago, isso foi proposital. Sabia que alguém iria comentar isso. Sim, a abstração de um repository é uma collection. Porém, pense do lado da Ubiquitous Language e Domain Model. Imagine que nosso domain model seja o próprio código, ou um diagrama de classe da UML revertido 1:1 do código. O repository vai estar com a operação save(Entidade). Você não vê que é uma rigidez conceitual dizer que tem que ser add(Entidade)?
Para a Ubiquitous Language isso é irrelevante. Simplesmente vou falar para o usuário. Tá vendo o Repositório de GradeCurricularItem? É naquela operação save que estará a regra de “um professor não pode estar em duas salas ao mesmo tempo” e “uma sala não pode ser ocupada por duas aulas ao mesmo tempo”. O usuário não sabe o que é uma collection, para ele, tanto faz.
Pode ser uma frescura nossa, do lado técnico, dizer que tem que ser add porque é uma collection. Vejo que o repositório é bom para:
- Concentrar as buscas
- Alocar as regras de existência da entidade (estado que a entidade deve estar para entrar no repositório, como exemplo, validações que fogem ao escopo do mecanismo de persistência, tem exemplo no código, como as próprias regras acima citadas).
- Desacoplar uma associação [um pouco mais raro]
- Atualização em lote
- Deixar tudo isso acima claro para os especilistas de negócio [se meu domain model é o próprio código]
O fato é que a tecnlogia que usamos hoje (JPA, Hibernate) tem dificuldades para validar o estado quando as entidades sofrem atualização, e muitas aplicações nós ainda usamos o merge. Mais uma vez acho isso frescura e mito que se criou. Aliás, pode chamar de DAO, pode chamar do que quiser, não vou me ofender (agora, chamar o @Embeddable de DTO isso sim me ofendeu). O cerne da questão é que é saudável ter uma abstração para concentrar as 5 coisas que coloquei acima.
Não sei porque tanta ofensa dizer que o Repository é Database-Driven. Ele é mesmo! 99% das vezes um repository está fazendo alguma coisa num banco de dados relacional. Se podemos abstrair ao máximo tudo bem, mas não vou cortar os pulsos se precisar usar um merge. Prefiro prezar pela simplicidade do que a rigidez conceitual.
:thumbup:Seja como for, estamos criando maturidade para um próximo artigo da Revista Mundo Java, uma coisa poderia até servir de prática, ter o GUJ como um julrado e contestador das melhores idéias.O que nos permitiria uma participação mais efetiva e menos publicitária, dando melhor conteúdo, status e credibilidade, para seu público, nada mais que os seus assinantes.
:idea:Uma idéia, antes da publicação ao referente artigo, fazer uma teste de mesa ao assunto, o GUJ tem essa capacidade, o que pode ser útil e de grande vália.Feito isso os melhores temas teriam uma votação por uma enquete sugerida pela comunidade e a revista as publicaria.
:thumbup:Vamos refatorar melhor nossas Idéias.
Não, não… a minha ideia tb não é essa… a minha ideia era fomentar um debate como esse sobre a tecnologia (leia-se a cultura DDD).
Todos sabemos que é perfeitamente possivel fazer um sistema sem usar DDD, seja este em qualquer nivel de complexidade, tamanho, etc… Arquiteturas mais simples resolvem o mesmo problema com muito menos esforço como o gerado pelo DDD no desenvolvimento, concordam?
Só pra constar, a “primeira parte” da materia que fala mais sobre o DDD e a OL está perfeita… como falei antes, acho que uma passada nos DDD Patterns deveriam conter esses debates…
[quote=rodrigoy][quote=sergiotaborda]
Se não nos apegarmos aos significados e aos conceitos e às suas representações reais seria uma bagunça inumerável e ninguem se entenderia.
Tlv vc aceite, porque os nomes foram escolhidos a dedo. E se vc tiver o mesmo conceito que eu, e estiver usando a mema nomenclatura é simples de aceitar…
[/quote]
Sergio, nem sempre padrões são explícitos. A API de InputStreams do Java é baseada em Decorators, nem por isso há menção clara a respeito disso, senão, chamaria BufferedOutputStreamDecorator. Muito da API do Swing é baseada em Observers e nem por isso consta em qualquer lugar que tal padrão é utilizado. Padrões são só soluções comuns. Um Visitor não precisa estar necessariamente implementado dessa maneira e com esses nomes para ser um Visitor.
[/quote]
Mas eu não lhe mostrei nenhuma implementação. “visitor” é o nome da variável. Para vc escrever o que escreveu acima é porque vc conhece o padrão. Por isso que o padrão é importante. Padrões são linguagem.
E esse era o ponto. O padrão só é util na medida que é entendido e implementado corretamente. Se uma dessas coisas falha, não ha padrão. Os DDD paterns são importantes porque são uma linguagem. Se vc quiser pensar recursivamente os DDD Paterns são a linguagem omnipresente da propria DDD. Entender e implementar esses padrões corretamente é usar DDD corretamente da mesma forma que implementar Cliente da forma correta é implementar o dominio de forma correta.
Não! Esse pensamento é completamente absurdo! Eu não leio Eisntein porque acredito nele. Eu leio para saber a opinião dele ( sublinho :opinião) e ficar a par do assunto que ele discute. Outros discutem o mesmo assunto sob o ponto de vista das opiniões deles. Etc… É pela sobreposição das opiniões que se entender o que o assunto é.
No fim , essa conversa toda tem que virar algo real, que funciona, que é utilizado.
Afirmar que se lê Fowler ou outro qq porque se acredita nele … putz não tenho palavras para dizer o quanto isso é absurdo!
Se aceitássemos nisso teria que aceitar que eu leio seus artigos porque acredito em si. O que não é verdade. Eu não acredito. apenas isto já mostra que as pessoas leiem as coisas de outras por muitos motivos, mas crença não é um deles.
Não ha uma relação de crença ou crédito quando se lê alguma coisa.
Após a leitura a pessoa tem a sua propria opinião e pode concordar ou discordar do que leu … mas “acreditar” não é um verbo que se aplica.
O problema é que isso não é verdade. Se fosse assim tão facil não existiriam inumeros topicos no guj e em outros lugares falando do assunto.
Existem dois fatores aqui:
- A pessoa se ilude que entendeu os padrões e que qualquer porcaria pode ser entendida como a implementação do padrão. Ou seja, o padrão é apenas uma ideia.
- A pessoa estuda o padrão e não consegue entender como o aplicar na vida real. Ou seja, o padrão é um conjunto de regras bem definidas que levam a um propósito explicito. Não são apenas ideias, são artefatos.
O que vc está defendendo é que o padrão é apenas um ideia (1). Reposiorio é apenas um qualquer objeto com qualquer interface que medie entre o dominio e o banco.
Eu não vejo assim. Repositorio NÂO é isso! :evil: Da mesma forma que Singleton não é apenas um factory que cospe sempre o mesmo objeto. O padrão existe por si mesmo. Aplicá-lo é que é a dificuldade.
è claro que o padrão não nasce se eu chamar “XXX” à classe, nem morre se eu nao chamar.
O exemplo do thiago é relevante. Repositorios não têm save. Pela simples razão que não estão ligados a persistencia. É isso que muitos ainda não entenderam. Repositorio não serve para persistir! ( Putz, é muito simples entender isso. Para vc que acredita no Fowler, basta ler que ele se refere a dois padrões: DataMapper e Repository. DataMapper é o DAO e o Repositorio não é o DataMapper, logo, não é o DAO)
É o conceito de Repository que está em causa. O seu conceito. No seu conceito (no de outros tb) Repository ter um add(), save() , persist(), sum() , retain() é tudo a mesma coisa. No nosso não é. Os nomes são importantes. A linguagem do padrão é importante. Ela é feita para ser seguida da mesma forma que a ubiquos language é feita para ser seguida. Padrão tb são linguagem. Tem que existir o mesmo respeito pelos nomes e conceitos dos padrões que ha pela ubiquos language para dominios. Caso contrário a comunicação é futil. Cada um dirá o que entender. Se chão-comum ninguem se entende. ( Veja o numero de topicos que falar de DTO mas chamar VO, coisa que ninguem chama à anos.)
não é aceitável que se identifique o padrão VO com o DTO ou o Repositorio com o DAO. Repositorio não é um DataMapper nem é um DAO. Ele não tem nada ver com persistencia. A persistencia é uma , eu disse uma , das possiveis estratégias para a implementaçãodo repositorio. É uma decisão tecnologica, não é uma decisão de design/arquitetura. O DAO é uma das estratégias (padrão strategy) do repositorio.
class Repository {
private RepositoryStrategy;
public Collection find(QueryObject q)
}
class DAOStrategy implements RepositoryStrategy{
private DAO dao;
}
class HashMapStrategy implements RepositoryStrategy{} (os nomes das classes são padrões , e não classes per se)
Repare no numero de niveis que separam o DAO do repositorio.
Esta mesma logica se poderia aplicar a outros padrões que vc diz ter implementado. Se não ha um seguimento correto dos padroes, então não é possivel afirmar que os implementámos. Padrões são coisas reais. são artefactos. Pessoas diferentes vendo o mesmo codigo vão saber que é o mesmo padrão.Até um algoritmo pode saber isso. É deterministico. Ou está bem feito, ou não está feito. Não existe “padrões semi-implementados” ou “esta classe é uma simplificação do padrão XXX”. Isso é POG. Puro e simples.
Sergio… OK… “concorda ou não concorda”, isso ocorre, e muitas vezes. Mas quais são os termos para vc concordar ou não? É determinista? Dê um exemplo de um autor que você não concorda.
Vc é apegado a rigidez conceitual eu não sou… Cara, na boa? Desenvolver software com você deve ser meio caro. :? Eu não vou criar uma pilha de classes só para dizer que estou usando um repositório “puro” por ter medo que se fizer diferente não vou ser entendido (ou criticado). Olhe o meu código e olhe o seu: qual deles é mais conciso em passar a idéia que estou querendo concentrar uma coleção de objetos? E pra que usar Strategy? Que cenário você enxerga que a implementação do repositório vai mudar em Runtime? (isso é um requisito apocalíptico :twisted: ).
O problema que vejo é que essa sua visão puritana das coisas acaba tornando as coisas inviáveis. Se tiver essa visão muito rígida nem DDD, nem TDD, nem XP, nem BDD, nem Scrum funciona. É conjunto de práticas. É EMPÍRICO.
É engraçado, vc diz que não “acredita” nas obras, mas sim “quer só saber a opinião”. OK? Se é assim, porque diz que devemos seguir à risca o que consta nessas obras? (nomes, conceitos, estruturas e etc…) E mais, que autor defende que devemos ter essa rigidez, principalmente com relação aos padrões?