Problemas na retenção e entendimento do conteúdo lendo livros como: Clean Code, Clean Arch, DDD, Design patterns..... e a sindrome do crud

Não posso te ajudar no que pede em primeiro lugar porque não sou especialista no assunto. E não sei se pode receber ajuda de fato de pessoas aleatórias na internet.

O que posso te dizer que recomendo mesmo ler esses livros. E recomendo antes de ler praticamente qualquer livro técnico ou de informação mais intensiva, ter criticidade. Ter poder de questionar, de entender completamente o objetivo do livro, de saber confrontar o que está lendo. Se não fizer isso o livro serve de lavagem cerebral, pra bem ou mal. Não pode usar esses livros como receitas de bolo.

Se prestar bem atenção com esses em específico e outros parecidos que todos recomendam, é que eles possuem inconsistências e coisas contraditórias. Não tem tanta informação assim neles que seja universal. Há um contexto, nem sempre relevado, em que eles foram concebidos. Eles podem servir muito bem aos autores e pessoas na mesma situação. Nem vou entrar na questão que pode não servir nem assim e só serve pro autor ganhar dinheiro com o livro porque isso acontece menos e é uma questão secundária. Por isso recomendo ler muitos, não um ou outro livro.

Boa parte das pessoas não vão usar, adequadamente, boa parte das coisas que são faladas nesses livros. Mas ainda tem muita coisa útil, até universalmente, e mesmo as outras seria bom você saber. Tudo ajuda a compor melhores soluções. Até para negar o uso, precisa conhecer. Negar porque não conhece não é uma boa ação.

Em alguns casos esses livros pregam complexidade. Tem caso que ela se paga, ela vem, mas ajuda em algo fundamental. Em muitos casos ela traz mais prejuízos que benefícios. Quem quer estar na moda, vai aplicar o que está lá sem questionar, ele só quer dizer que fez "certo", que adotou o que o livro mandou. Isso chama-se religião, não engenharia.

Se você usar qualquer técnica mais avançada desses livros em projetos pessoais é quase certo que está usando errado.

Boa parte dos códigos da maioria das pessoas será CRUD. A questão é que algumas coisas extras e alguns detalhes que vem logo depois do CRUD precisam de aprofundamento. Precisa entender de computação. Coisa que esses livros não tocam muito. Esses livros não falam de fundamentos, falam de coisas mais avançadas.

Só um detalhe, CRUD deveria ser questão solucionada. Não pegou a "modinha" de automatizar isso e programador gastar seu tempo com coisas mais nobres.

Um dos maiores erros que eu vejo é as pessoas fazerem o acabamento da casa sem ter sequer o alicerce. Aí fica difícil entender tudo. Sem matemática, comunicação e expressão, e ciências, pode complicar. Como a pessoa fará um design pattern quando ela não sabe o que é uma variável, mesmo o que pensa que sabe. Ou mesmo usar bem isso quando o livro dá uma definição muito contextual daquilo. Uma variável é o design pattern mais usado pelo programador. Sabia disto?

Quando não se sabe a base, todo o resto fica torto.

Em alguns casos os cursos realmente podem ajudar muito, se eles forem bons. Grupo de estudo pode ajudar, não há dúvidas disso. Mas se todo mundo for fraco ali pode dar muito ruim. Se tiver alguém que não é, então não é um curso, mesmo que gratuito?

Só te garanto que tudo o que aprender não será suficiente na área. Sempre precisa de mais. Faço isso há 40 anos só na área e ainda sou uma porcaria, mas menos do que era antes. O que mais me ajudou foi ter os fundamentos e ser questionador.

Farei algo que muitos pedem para aprender a programar corretamente, gratuitamente. Para saber quando, me segue nas suas plataformas preferidas. Quase não as uso, não terá infindas notificações (links aqui).

Vou deixar meus 5 centavos de contribuição.
Tem uma ordem sugerida para ler os livros e para você incrementar o conhecimento, você começou pelos livros de arquitetura (DDD, Clean Arch), fatalmente cruds vão te irritar com tanto conhecimento.
Para estes livros de arquitetura tenha um pet project (um projetinho que goste de fazer) eu tenho um aqui de atualmente de finanças pessoais, já usei um de locadora por muito tempo. Tenha regras de negocio bem estabelecidas, estude requisitos de arquitetura e estabeleça alguns para seu projeto. Execute ele conforme as propostas de DDD, Clean Arch, N Camadas, Event Driven, tente fazer em outras linguagens, participe de grupos de discusão, isso vai te ajudar muito a entender a aplicabilidade das coisas que está estudando nestes livros.
Entenda onde não usar, entenda quais são os prós e contras de cada abordagem.
Igualmente importante pensar isso para desing patterns, onde não usar, hoje alguns livros trazem a resposta desta questão, hoje eu considero o https://refactoring.guru/design-patterns a melhor fonte de design patterns, pois além descrever onde usar e não usar de forma bem clara, tem UML do pattern e exemplos em muitas linguagens distintas.
Para os cruds do dia a dia, faz parte passar por eles, afinal como um colega citou faz parte do pareto 80% 20%.
Recomendo que leia os topicos / livros na seguinte ordem e tente aplicar, sempre mantendo uma boa dose de discusão sobre os temas com os colegas. Afinal "Se quiser ir rápido vá sozinho, se quer ir longe vá acompanhado."

• Boas praticas
  • Livro: O programador pragmático
  • TDD - Testes de unidade
    • Livro: TDD do Mauricio Aniche Casa do código (tem varias edições em linguagens diferentes escolha a que mais lhe agradar)
    • Livro: Trabalho eficaz com código legado
  • SOLID
    • Não precisa ler um livro, se puder pegue exemplos na internet, entender o que é cada letra dos principios é relativamente facil, entender onde aplicar e não aplicar é o mais importante. OBS: O Filipe Deschamps tem um video muito bom sobre no canal dele.
  • Livro: Clean code
  • Livro: Clean coder
  • Algoritimos
    • Livro: Entendendo Algoritmos: Um Guia Ilustrado Para Programadores e Outros Curiosos
    • OBS tem muitos livros de algoritmos variados estudar eles vai te dar um alcabouço de muitas ferramentas para resolver problemas complexos.
• 12 Fatores de aplicação
  • https://12factor.net/pt_br/
• Patterns e Praticas
  • GOF https://refactoring.guru/design-patterns
  • Livro: Padrões de Arquitetura de Aplicações Corporativas
  • Livro: Refactoring
• Entenda CI CD - DevOps - SRE
  • The Mythical Man-Month - Este livro é focado em gestão, eu colocaria ele aqui na sequencia leria o =>
  • Livro: O projeto Fenix
  • Depois tem materias especificos para cada topico, tem bastante coisa na internet
  • SRE livros do google - Online leitura FREE https://sre.google/books/
• Arquitetura
  • DDD Livrinho azul do evans
  • DDD Livrinho capa vermelha do Vernon
  • Microserviços pronto para produção
  • Arquitetura de software distribuído: Boas práticas para um mundo de microsserviços
  • Manual do arquiteto - https://arquiteturadesoftware.online
  • Arquitetura de software distribuído (casa do código)
  • Software Architecture: The Hard Parts: Modern Trade-Off Analyses for Distributed Architectures
  • Designing Distributed Systems: Patterns and Paradigms for Scalable, Reliable Services
  • Designing Data Intensive Applications
  • Reactive Messaging Patterns with the Actor Model

Tem muito material ai, vai na calma e no seu tempo, estudando e aplicando, divirta-se na jornada, não se cobre demais, não extresse com os cruds.

Minha dica para fugir do CRUD é me aprofundar na ideia não precisa ser algo inovador.

Geralmente quando quero fazer um sistema eu escrevo uma proposta técnica como se um cliente estivesse me solicitando o sistema. Com base nesse documento eu vou desenvolvendo o projeto de estudo.

Eu começo com um mini-mundo e vou explodindo a ideia até começar a entender os requisitos funcionais e etc. Depois vou dividindo o projeto em atividades e vou implementando pedaço a pedaço dessa maneira eu consigo aplicar tudo que preciso estudar.

Ultimamente eu tenho escrito ideias sem parar. Quando eu precisar de algum projeto para aplicar algum conhecimento eu já tenho.

Decidi trabalhar dessa maneira depois de ler o DDD e por experiencia própria entender que o programador tem que entender a regra de negócio se não o sistema final vira um ornitorrinco kkk

Inclusive boa parte dos livros que você citou explica isso, sobre a importância de entender a regra de negócio e como refletir no que está sendo desenvolvido para entregar valor e não cair no meme do balanço.

Sobre os livro e os design patterns não posso falar muito porque também tou na mesma situação, ainda tou tentando aprender mais sobre, até porque sofro com os problemas de arquitetura todos dias (num local onde primeiro a gente coda um monte de CRUD sem nem sequer saber as regras de negócio) tem aplicações que eu desenvolvi praticamente sozinho do zero até hoje n sei pra que servem direito. No meu caso estou faz sentido buscar este tipo de tema pois sinto muita falta. A cerca do Clean é muito mais a ver com implementação. Já no meu caso falta DDD na cultura da empresa e isso não tem como eu fazer muito... O DDD ta mais na forma de pensar do que código em si e mesmo assim não se aplica a todas situações, o que tenho feito esses dias são exercícios mentais "brincando" com o GPT. Ele finge ser meu cliente e eu tento chegar numa análise de domínio pro problema que ele precisa.

Ja acerca do CRUD, o que eu tenho feito é desenvolver outros tipos de projetos pessoais, atualmente tou trabalhando numa implementação do protocolo tus pra Rust, criando uma lib que integra no framework Rocket, além disso também tive fazendo projetos mais a ver com componentização de software e assembly loading em C#. Tenho feito essas coisas que dinsriguem de ficar montando CRUD, projetos que buscam aprender coisas novas não só mais do mesmo.

Ja passei por isso, e após alguns anos posso te dizer que alguns desses livros tentam te ajudar a resolver um problema, porem se voce nao passou por aquele problema nao vai conseguir entender e absorver a informação.
O DDD é um exemplo disso, ele é um livro muito focado na analise do negócio e como resolver as dificuldades do mesmo (Entendimento e Implementação), como alternativa pode tentar ler "Implementando Domain-Driven Design" que é mais voltado para tecnologia.
Outro exemplo é o Refactoring, voce começará a entende-lo melhor quando passar a trabalhar com código de terceiros, ate lá, vai ficar na teórica, voce ate pode fazer no seu proprio codigo, mas nao é a mesma coisa.

Acho que o mais importante é voce saber que existe uma boa pratica ou um design para quando tiver o problema saber como resolver.

Estão exigindo bastante. Apesar de saber as coisas, ter experiência, eu tomo ferro na entrevista técnica.
Para eles é assim:
Você é brasileiro?
Sim, sou.

Cite todas as capitais do Brasil!
Você esquece uma.

O DEV que está te entrevistando também não sabe, ele consulta as anotações dele. E depois,

Não passou confiança técnica. Você não serve, você não é brasileiro. Estamos procurando por brasileiros.