Infelizmente eu acabo passando um pouco por isso no dia a dia. Acabo nas minhas implementações fazendo muito pattern e camada pra desacoplamento que depois acaba complicando um pouco o time.
Mas eu consigo até me justificar o problema é que nem sepre

• Praticamente todas as vezes

Fazem a análise do domínio e isso atrapalha muito, porque a gente acaba programando sem nem saber o que aquilo vai fazer. Eu tou num projeto a mais de 1 ano que eu praticamente fiz do zero e se me perguntarem sobre o negócio eu não sei praticamente nada daquilo. Aqui a cultura é fazer tabelas no banco e depois montar aplicação por cima disso. No meu caso eu acabo programando nas cegas, não faz sentido nem ter um DDD definido e já ir logo fazer relacionamento com as tabelas.
É a tal história do "Assa um pizza ai, mas depois eu escolho o sabor".

O problema nem sempre tá no dev que implementou esses monte de overengineer mas sim na parte superior, que não transmite bem o conceito do negocio.

Enfim acaba que fica como um desabafo aqui pra vocês.

Tenho estudado muito mais sobre DDD e análise de sistema do que código em sí e isso tem aberto muito meus horizontes para conseguir criticar aquilo que faço no dia a dia. E quando eu falo de DDD não é fica fazendo pasta e sim sentar com o cliente, levantar requisitos, estabelecer uma linguagem oblíqua, fazer uma prototipagem e todo o resto. To cansado de começar pelo código e depois descobrir que os meses que passei pensando que aquilo na verdade era pra ser outra coisa e depois no fim acaba que fica tudo remendado nas gambiarras porque agora já não tem tempo de refazer tudo de novo.

Com isso deixo aqui um conselho ao escritor do post: As vezes o problema aí é falta de comunicação e planejamento prévio. O que depois acaba causando essas frustrações.

Seu post foi como alguem falando de um lado e eu respondendo do outro kkk

muito foda essa comunidade!