00:58:46 Ports and Adapters 01:06:02 Ponto importante da mudança de arquitetura 01:16:45 Gatilho da "Refatoração" 01:21:28 Lado do Driven Actors 01:36:19 Balanço do refactory
Só quero pontuar uma coisa aqui. o branas tá falando alí no começo que ele tá fazendo TDD mas na real ele não está 100% fazendo TDD pois no caso do TDD tu teria que estabelecer as condições para que o teste passe antes de fazer a implementação, daí que vem o Red / Green / Refactor. Faltou ele pontuar isso.
Esse mundo tá muito doido! Do nada comecei a ouvir falar em arquitetura limpa, lá do veinho bob... agora essa hexagonal... daqui a pouco vão aparecer mais 3 ou 4 sei lá... nunca se sabe... mais de 30 anos como desenvolvedor nunca vi isso levar a nada, por no final das contas o que importa é o resultado e para empresas o lucro e sempre vai existir o jeito brasileiro. Quanto ao cliente quem se importa, não entende mesmo... só empurrar qualquer solução garganta abaixo, que ele paga! Poderia achar uma Arquitetura Brasilereis. Eita inventei uma palavra! KKKK
Existem aplicações e aplicações, se é algo crítico, um banco por exemplo, vc deve levar em consideração clean architecture à risca, pois é uma aplicação que irá ser mantida por décadas, ou seja, no meio do caminho pode acontecer de precisar mudar o banco de dados, sistema de notificação, sistema de monitoramento, logs, etc., ou seja, se vc criar a aplicação acoplada à tecnologia/biblioteca, se vc precisar mudar de biblioteca, vc vai precisar mexer no domínio da aplicação. Imagina cenários que é identificado graves vulnerabilidades em uma biblioteca que está acoplada no seu código, exemplo recente é o log4j, para quem usava inversão de dependência foi simples substituir para outra lib de log, mas quem não seguiu as boas práticas se lascou. Imagina ter que mudar um gateway de pagamento, sendo que seu código estava amarrado com o PayPal. Mas como eu disse, existem vários tipos de aplicações, e a maioria não precisa usar Clean Architecture no nível xiita, basta saber quais são os módulos críticos e ter mais cuidado nos acoplamentos criados nesses módulos. Tão importante quanto saber desacoplar, é saber o porque de desacoplar.
00:58:46 Ports and Adapters
01:06:02 Ponto importante da mudança de arquitetura
01:16:45 Gatilho da "Refatoração"
01:21:28 Lado do Driven Actors
01:36:19 Balanço do refactory
O Curso da Full Cycle é muito bom. Me ajudou a evoluir e deu norte para muitas coisas. Brans, que conteúdo top. Parabéns pela didática!
Branas é fora de série. Que didática!
Eita, mais uma aula fantástica do Branas.
Valeu povo do Full Cycle, por mais esse show
Muitos conceitos que eram obscuros pra mim ficaram claros como água depois dessa live, obrigado Rodrigo Branas, você é monstro.
Aula simplesmente espetacular.
Show de bola, parabéns por mais uma excelente apresentação.
A live teve solo de Sweet Child O' Mine em 1:57:41
Muito top
Que aula f###da
Só quero pontuar uma coisa aqui. o branas tá falando alí no começo que ele tá fazendo TDD mas na real ele não está 100% fazendo TDD pois no caso do TDD tu teria que estabelecer as condições para que o teste passe antes de fazer a implementação, daí que vem o Red / Green / Refactor. Faltou ele pontuar isso.
@devfullcycle
@rodrigobranas
@argentinaluiz
Que o Sucesso de vocês seja sempre constante!
Esse mundo tá muito doido! Do nada comecei a ouvir falar em arquitetura limpa, lá do veinho bob... agora essa hexagonal... daqui a pouco vão aparecer mais 3 ou 4 sei lá... nunca se sabe... mais de 30 anos como desenvolvedor nunca vi isso levar a nada, por no final das contas o que importa é o resultado e para empresas o lucro e sempre vai existir o jeito brasileiro. Quanto ao cliente quem se importa, não entende mesmo... só empurrar qualquer solução garganta abaixo, que ele paga! Poderia achar uma Arquitetura Brasilereis. Eita inventei uma palavra! KKKK
Existem aplicações e aplicações, se é algo crítico, um banco por exemplo, vc deve levar em consideração clean architecture à risca, pois é uma aplicação que irá ser mantida por décadas, ou seja, no meio do caminho pode acontecer de precisar mudar o banco de dados, sistema de notificação, sistema de monitoramento, logs, etc., ou seja, se vc criar a aplicação acoplada à tecnologia/biblioteca, se vc precisar mudar de biblioteca, vc vai precisar mexer no domínio da aplicação.
Imagina cenários que é identificado graves vulnerabilidades em uma biblioteca que está acoplada no seu código, exemplo recente é o log4j, para quem usava inversão de dependência foi simples substituir para outra lib de log, mas quem não seguiu as boas práticas se lascou.
Imagina ter que mudar um gateway de pagamento, sendo que seu código estava amarrado com o PayPal.
Mas como eu disse, existem vários tipos de aplicações, e a maioria não precisa usar Clean Architecture no nível xiita, basta saber quais são os módulos críticos e ter mais cuidado nos acoplamentos criados nesses módulos.
Tão importante quanto saber desacoplar, é saber o porque de desacoplar.