1

Arquitetura de software pode ser intuitivo, e menos "padrões"?

Arquitetura de software, em si, não se parece com nada. Diferente ouvir isso, né?

É como uma escolha dentro de um conjunto maior de outras escolhas e assim por diante.

E todas essas escolhas são consideradas.

Claro, algumas precisam ser mais rápidas e decisivas, outras mais ponderadas, por serem suficientemente próximas da "imagem maior" do sistema e impactar diretamente essa jornada.

Mas entende? Não é um padrão. Uma lógica. Uma ferramenta.

Arquitetura de software é a jornada inteira: do começo, onde se sabia pouco ou nada, até o durante, onde já se sabe alguma coisa relevante.

Por isso gosto da visão do Robert C. Martin sobre a suavidade dentro de um sistema. Mudar algo nunca deveria exigir uma completa transformação naquilo que foi feito.

Se exigir, então você quis prever o imprevisível.

E no nosso ramo nós trabalhamos com código, não com bola de cristal 🔮

Bons estudos, pessoal 📚

Carregando publicação patrocinada...
3

OS livros de Robert C. Martin são realmente muito bons e servem como referência, e foi realmente isso que me fez enxergar que o uso inadequado de DDD, Clean Arch, etc de maneira total sem noção, pode criar muitas camadas ao ponto de entrar em overengineering (sim, um projeto legado mal escrito pode ser mais simples de trabalhar que arquitetura aplicada no Go Horse).

Trabalhei em um projeot PHP Laravel em que fizeram o uso de DDD, dentro de DDD, e capando camadas importantes... E no final, para editar uma regra de negócio simples, era 50 cadamadas para encontrar um if com enum. Mais parecia várias camadas de uma cebola dentro e uma cebola, acopladas entre outras cebolas como se fosse microserviços (mas na visão do arquiteto não era micro serviços).

Um projeto bem estruturado com Clean Arch, se torna muito mais fácil de fazer manutenção, mas ao mesmo tempo se usado de maneira incorreta pode se tornar algo que somente o criador consegue lidar.

1

Que comentário pertinente! Obrigado, meu amigo.

Gosto da simplicidade e coesão extraordinárias dos livros dele. É fácil de compreender, divertido e completo.

De fato. Por isso, o autor se delonga em explicar no início que, para alcançar o resultado desejado – a saber, um bom design de software – deve-se primeiro entender a mentalidade e objetivo corretos do arquiteto. É realmente uma forma de pensar, com regras. Sem segredos. Regras.

Obrigado de novo!