Vou falar da minha experiência. No início, quando eu estava aprendendo, me parecia muito mais natural programar orientado ao banco, tanto que eu começava pelo banco, era mais fácil pensar assim. Hoje em dia, depois de estudar mais, arquitetura limpa, arquitetura em camadas, etc, é o contrário. O banco, eu vejo apenas como uma tecnologia de persistência e acaba sendo uma das últimas coisas que faço no projeto. Antes disso, o código é todo orientado ao negócio, o famoso DDD. O core de tudo é o que o código faz, quais regras de negócio ele tem, quais validações, quais entidades(entidades de código, não de banco) fazem parte do negócio. O código funciona independentemente do banco. O banco apenas persiste e recupera os dados. Se amanhã, eu quiser deixar de usar um banco relacional pra usar um no-sql, eu simplesmente troco o adaptador do banco e uso outro, sem afetar o propósito da aplicação. O banco é apenas uma ferramenta, uma tecnologia de persistência. Mais do que isso até, a própria API, libs externas, infra, seu eu quiser eu troco por outra, eu troco sem grandes dificuldades. Toda a tecnologia que permeia o código, são mais detalhes de implementação do que algo que tenha a ver com que o código ou negócio, que é o principal.

E porque seria assim? O banco é "descartável", as coisas só estão ali porque a aplicação(quando tem uma aplicação), colocou. Poderia ser esse banco ou qualquer outro, as coisas, se fossem orientadas ao banco, seriam sempre diferentes. Mas o banco só serve pra persistir dados e nada mais. Já as regras de negócio da sua aplicação, elas só mudam se o negócio mudar, assim como o banco também deveria mudar. Por exemplo, você modela na aplicação que um usuário pra realizar determinada tarefa no seu site deveria ser maior de idade, isso é uma regra de negócio. Você então determina isso na aplicação, faz as validações implementando essa regra. Essa regra pertence ao domínio porque é uma ideia, uma regra de negócio, ela pertence ao "código" porque a regra é primária, ela não depende de como os dados são salvos. As restrções dos bancos devem servir apenas pra manter a normalização dos dados, aintegridade, a consistência dos dados, etc. Não interessa AO BANCO se um número tem que ser maior de "18 anos" ou não, aliás, o banco só trata um número, o conceito de restrição de IDADE, se trata de negócio/código.

Então se fosse pra ser curto e grosso, eu diria que o código é orientado ao negócio e vem antes de pensar sobre como os dados serão modelados ou salvos, o banco não é orientado a nada, só serve pra persistir. No seu caso, é como se o "código" estivesse na sua cabeça, você pensa que orientou algo aos dados, mas não, você orientou o banco à sua necessidade. O código faz isso, ele modela a sua necessidade, agora se é o banco A, B, com tecnologia X ou Y, se vai salvar na nuvem, na memória, no disco ou onde for, isso não interessa.

manierohá 7 dias

De fato não interessa o banco. Em parte.

E você já fez essas coisas todas que diz aí?

A minha experiÊncia de mais de 40 anos é que as pessoas acreditam nisso mesmo, mas elas não sabem na prática como é. E acaba acontecendo duas coisas:

a) o sistema era tão simples que qualquer coisa serve e nunca haverá necessidade real de trocar nada, qualquer porcaria que a pessoa fizer vai dar conta, até tudo errado. b) o sistema precisa ser muito bem arquitetado para aguentar o traco, e na rara ocasião que precisará trocar o banco de dados especialmente, mas pode valer para outras coisas em menor grau, significa que já está ruim por ter criado camadas desnecessárias e não otmizadas para acessar o DB, a tal da arquitetura limpa é extremamente s uja, e justamente por ter feito isso é que pode ter surgido a necessidade de trocar algo. E se trocar não vai melhorar muito a não ser alguma questão pontual, e um dia vai aparecer questões novas que mostrará que a troca não foi perfeita. E para arrumar e deixar bom mesmo a silução será arracar essa camada que abstrai o banco de dados e usá-lo da forma correta a ser definida por um profissional competente nisso.

Na ausência de alguém competente o que acaba acontecendo é a adoção de aruiteturas mais complexas ainda, por exemplo o uso de microsserviços para resolver um problema que nem deveria estar ali. Eu já dei consultoria que fizeram tudo isso para dar perfomance, e eu só mandei tirar, fazer o simples e a performance veio.

Essencialmente nenhum caso precisa trocar de banco de dados, todos os mais conhecidos dão conta do recado nas mãos de quem sabe o que está fazendo, não importante o tamanho da bronca que está segurando. Até o SQLite, agora com tecnologias prontas pode dar conta em grande parte dos cenários (ele já dava no básico em muitos deles, pra quem sabia usá-lo).

O banco de dados é só uma forma de armazenamento quando está atrás de uma aplicação. Tem usos diretos que é diferente. Mas não quer dizer que ele não deva ser otimizado.

Uma boa estrutura resiste a mudanças de negócios mais facilmente, se o banco for modelado pensando no que o negócio precisa dá muito mais trabalho, e foge da ideia de que ele é só um meio de armazenamento. Ele deve se preocupar em armazenar bem, não modelar o negócio bem. Quem tem que modelar o negócio é a aplicação.

Todas essas técnicas "modernas" como DDD, CA , etc., tem lá seu valor e cabe em alguns cenários, mas as pessoas precisam estar cientes dos custos que isso tráz, e quase ninguém analisa isso, usa porque "todo mundo" está usando (segredo: só uma minoria está usando mas só bem vocais), ou seja, apesar da ferramenta ter algum valor, a forma como se decide usar é modinha, é "boa prática" 9que está virando um vídeo no meu canal que estreará em breve e texto no meu blog, porque provavelmente é problema mais grave e frequente que se comete e "ninguém" fala dele.

S2

Farei algo que muitos pedem para aprender a programar corretamente, gratuitamente (não vendo nada, é retribuição na minha aposentadoria) (links aqui no perfil também).

devmaykehá 7 dias
Sim, coloco em prática tudo o que aprendi em produção e desde então, me facilitou demais problemas com bugs e manutenção, principalmente porque vários dos problemas críticos que podem acontecer na aplicação estão garantidos pelos testes. A ideia de mudar o banco é meramente ilustrativa, e me serviu de exemplo pra dar o tom do que é mais importante na aplicação, em um projeto que começa do zero. Ou você vai me dizer que o principal é o banco e o código, e negócio, é secundário? É claro, que raramente se precisa mudar. O ponto todo é que não tem porquê, de forma alguma, acoplar o banco a troco de nada, a troco de não usar um simples pattern de repository ou adapter na aplicação, que implicaria em uma arquivo de interface e uma injeção de dependência, onde em uma tarefa rotineira, não implica em muito mais trabalho e não diminui em nada a performance... não que você ou alguém em experiência de uso notaria. Eu olho pra um projeto "clean code" e sei onde as coisas estão, pode haver diferenças aqui e ali, mas mesmo essas mudanças são padrões. Se levarmos o princípio da menor surpresa em consideração, o que parece complexo pra quem não conhece, se torna muito comum e fácil de entender pra quem conhece. O complicado mesmo é o "simples" que pode ser feito de muitas maneiras diferente, e como ninguém segue padrão nenhum, cada um faz do seu próprio jeito. Nos outros casos, na gisgantesca maioria das vezes, é como você falou, claro que ninguém precisa usar microserviços. Isso é uma coisa que não se usa atoa. Mas em um time onde todo mundo conhece, seja "clean code", mvc, ou qualquer arquitetura em camadas que seja de conhecimento comum, não acredito que isso aumente a complexidade. Patterns, são repetitivos, as pessoas olham e inituitivamente reconhecem as coisas. Garanto pra ti que o mundo do software sofre muito mais por código bagunçado onde cada um faz do seu jeito "simples", feito de qualquer maneira, do que pela tal do over enginering. E todo projeto tem sua particularidade. Um projeto menor, não precisa ser implementado à risca o clean code. A questão das camadas é algo muito simples de se implementar. Por mais simnples que seja o sistema, colocar tudo dentro do controller achando que as coisas vão ficar mais simples ou mais rápidas, não vai resolver. Se você apenas separasse o seu caso de uso/service do controller e chamasse as operações de banco de outro de outro arquivo, injetando as dependências, essa simples separação já te colocaria em 70% do que é a clean arch. E foi feito o básico do básico na sua aplicação, sem comprometer em nada a legibilidade, a complexidade do seu projeto. Complexo é analizar um arquivo com 800 linhas.... Parece que o clean code é muito complexo na teoria, mas na prática é bem simples. Tem coisas que, seguindo boas práticas óbvias de desenvolvimento como o SOLID por exemplo, intuitivamente, o código fica "limpo". Não é uma questão de nomear pastas e arquivos, é onde as coisas devem ficar. Já viu um programador experiente, amontoar responsabilidades e acoplar funcionalidades em prol de "simplicidade" no código? Isso não existe, naturalmente, a sua aplicação vai ter camadas e em casos que você não quer acoplar uma lib externa, de repente um banco porque talvez você não confia, na verdade, não que você não confie no banco, mas talvez você não confie na estabilidade do ORM que você utiliza pra acessar o banco... seja qual for o motivo, esse tipo de desacoplamento é básico pra qualquer programador experiente. Não tem nada de complexo, trabalhoso demais ou mais lento em implementar isso. A gente tem um monte de termos e nomes técnicos e bonitinhos pra falar de código, e que virou modinha, mas a verdade é que programadores experientes fazem isso a anos sem dar nomes aos bois. Ou o código está todo em seu devido lugar, não misturando muitas responabilidades, não muito acomplado, não se repetinfo muito, ou, o código está todo feito de qualquer jeito sem se preocupar com nada. Não tem muito pra onde correr, você pode odiar o termo, a modinha, mas a ideia toda, no núcleo, está correta. Talvez não esteja correta nos detalhes, mas essencialmenbte, falar mal de clean code, ao meu ver é insanidade.