Voce poderia me mostrar isso na Spec?
Eu já li e não me lembro dela falar que esse é o único modo de usar.
Eu vejo que é flexível o bastante para deixar voce escolher sua abordagem. Por isso JPA suporta tantos tipos de herança, override de nome de colunas, indexes, etc…
Poderia tb me mostrar em que caso OO está em desuso? Nunca vi uma referencia a isso.
Quem esta dizendo que a abordagem DB first faz parte do JPA é você, então é mais lógico você mostrar onde isso é definido na especificação.
Eu estou dizendo que não existe isso na especificação, logo não faz sentido você pedir pra eu “mostrar isso na spec”. Você quer que mostre o que? 
Não entendi qual a relação. A especificação JPA fala claramente sobre tipos de herança, mapeamento de colunas, indexes. Até onde sei, a especificação não fala de abordagem DB first.
Por isso seria bom citar onde você vê ela falar sobre DB first.
No backend. Mas é apenas uma impressão dado a quantidade de vagas pedindo conhecimento em linguagens funcionais que tenho visto ultimamente.
A primeira pessoa a falar de Spec foi voce. Por isso te pergunto novamente, voce poderia mostrar onde ela fala para usar Model First? Ou melhor, voce já leu a Spec alguma vez? Me parece que voce está afirmando algo em uma documentação que você, pelo visto, nunca leu.
A spec determina que o modelo deve refletir o banco de dados. Qual a diferença entre começar com o DB ou com o modelo? Se o DBA fez o modelo, crie seu código. Se o Dev fez o modelo, crie seu banco. Ou seja, vc pode optar qual a abordagem que voce quer e seguir. Se voce tem essas duas opções, onde está a limtação em fazer DB First ou Model First?
Quanto ao ‘desuso’ de OO como foi baseado em impressão, isso é mais opnião para mim. Como cada um tem a sua isso não adianta discutir se não á dados. ( :
Na introdução, uma vez que toda a especificação é sobre model first:
This document is the specification of the Java API for the management of persistence and object/rela- tional mapping with Java EE and Java SE. The technical objective of this work is to provide an object/relational mapping facility for the Java application developer using a Java domain model to manage a relational database.
Agora podemos saber onde a especificação fala sobre DB ser modelado primeiro ou você vai continuar inventando desculpa e tentando desqualificar o debatedor?
zzzzZZZZZZzzzzZZZZZZZzzzzz
A diferença é que uma é abordada na especificação JPA, a outra não.
Citando o pedaço da Spec que pelo visto foi rapidamente (ou incorretamente) lido:
to provide an object/relational mapping facility
Facilitar o mapeamento. Engraçado… não vi nada falando sobre model first ou mesmo DB first. O que eu to tentando falar é: JPA é agnóstico a quem é criado primeiro. O JPA funciona independente de quem veio antes. A Spec é adaptável a qualquer situação. JPA serve para facilitar o uso de OO com o DB.
using a Java domain model to manage a relational database.
O que voce entende por manage? Criar modelo primeiro para acessar o banco?
Honestamente acho que estou desqualificando a leitura em ingles do debatedor. Pq o texto que voce colocou mostra apensa que o JPA facilita a manutenção/utilização do DB, e em nenhum momento fala que o modelo tem que ser feito primeiro.
Novamente, me mostre que não. Bem, acho que vou parar de discutir Spec com quem está lendo a introdução as pressas e querendo argumentar.
Nas empresas de desenvolvimento moderninhas, orientação a objetos está em desuso no backend.
Eu parei de ler nessa parte, sinceramente.
Acho que desenvolvedores experientes precisam ter responsabilidade com as informações que são colocadas na internet, pois isso aqui será utilizado muitas vezes como referência dos recém-chegados no futuro. Estamos numa área de EXATAS onde uma opinião sem dados vale pouco, muito pouco.
De qualquer forma, quanto ao JPA eu particularmente utilizo com schema validation, pois sempre desenhei meus databases a parte (seguindo as 3 primeiras das 5 formas normais) e peço pro JPA validar, pois acho que consigo tirar o melhor dos dois mundos. JPA até agora me serviu bem tanto pra spec Java EE tanto pro ecossistema Spring. Por sinal, Spring Boot com JPA, REST, MVC eu atualmente considero a stack mais produtiva para programadores Java experientes (já brinquei com a stack MEAN e Ruby para efeito de comparação).
Um parça gente boa (Bruno Gasparotto) me indicou o webarchive. https://web.archive.org/web/20161228051356/https://uaihebert.com/
Já tinha sido indicado aqui mesmo no tópico! E como te falei, se um dia tiver tempo pra administrar seu blog de novo, te ajudo a subir tudo de novo =]
Não tem nada de agnóstico ou adaptável. A especificação é sobre usar o domain model para gerenciar o banco. Isso inclui gerar o schema a partir do código Java.
É uma coisa óbvia pra quem leu a especificação ou quem trabalhou com JPA.
Quando tiver um tempo, sugiro que leia o pacote javax.persistence.schema-generation e o pacote javax.persistence.code-generation… ops, brincadeira esse último não existe. 
Sim, é o melhor que vc faz visto que não tem nada pra citar e sua tentativa de desqualificar o debatedor não parece estar dando certo.
O JPA na sua stack apenas significa que sua experiência é baseada em aplicações CRUD simples.
Não que tenha algo de errado nisso, tem muita demanda por esse tipo de sistema no mercado. Mas JPA jamais estará presente em sistemas que precisam escalar.
E REST com MVC… como isso é possível? 
rapaz do céu que treta mininu, eu aposto no UAI Hebert saindo vitorioso! rsrs
Olá @Hebert_Coelho,
Uma pena seu site ter saído do ar, pois era uma referência pra mim e pra muitos outros colegas. Faço votos que você volte em breve, pois faz muita falta.
Muito legal você esta tendo essa experiência internacional, se fosse possível você fazer um vídeo falando do mercado de trabalho ai na Alemanha, seria bacana.
Como em qualquer parte na internet existe troll, o GUJ não é diferente. Por fim como diria um amigo meu “não alimente os Trolls”, apenas ignore.
Boa, kkkkkkkk isso mesmo não dê cachaça para os Trolls, quer dizer os Troços do Sub Treco.
Independente de DB First, é da cultura da comunidade Java (principalmente) querer abstrair ou desacoplar tudo mesmo sem necessidade. Como por exemplo, abstrair SQL mesmo com a empresa usando somente bancos de dados relacionais, criar Interfaces sempre, mesmo para uma única implementação contratada, etc.
Acho que empresa moderninha nem deveria usar Java, deveria usar Go, assim fica livre dessas pregações que tudo deve ser OO, MVC, etc. Fora isso, pelo que vejo infelizmente ainda continuam sim usando muito JPA/Hibernate, mesmo já tendo opções intermediárias mais leves. Sobre excesso de engenharia é verdade, é uma ferramenta pesada, e deveria ser usada quando existisse necessidade para o resultado, não só para consumir mais recursos.
Opa Namor, tudo bem? Cara Herbert eh amigo meu, ele começou a ficar muito sem tempo e nós dois nos mudamos do Brasil quase na mesma época, ele ta morando na Alemanha e tem tido algumas outras prioridades, mas pra frente ele deve voltar com o site. Viver fora é meio pancada principalmente no começo, mas uma hora as coisas começam a ficar mais folgadas.