Assunto bem legal com pouquíssimo conteúdo em português. Acredito que esse seja o primeiro canal brasileiro de arquitetura a dar visibilidade de prós e contras pra essa estratégia. Vlw por trazer o ponto de vista sobre a Vertical Slice
Pq vc pensa isso? Pelo q entendi, apenas se a equipe resolver seguir uma implementação mt diferente pra cada feature poderia causar problemas. Mas se toda feature tiver uma guideline (cotroller, service, dao) me parece ser mais fácil para integração de novos colaboradores e manutenção a longo prazo. Nota: Estou apenas estudando o tema, nunca apliquei na prática, estou comentando com base em impressões pessoais e gostaria de saber outras visões.
Acho interessante uma abordagem de arquitetura hexagonal/onion/clean com o uso de Vertical Slicing dentro do adapter de interface, para aplicações com o UI complexo. A componentização ou separação por features é muito mais natural no frontend.
Ótimo vídeo como sempre, mas acabei não concordando muito com suas desvantagens. Você tratou o padrão como uma prática de transição apenas. A maioria dos problemas apresentados foram relacionadas às transições e refatorações em si e não à arquitetura. 1 - Confusão sobre qual organização deve ser usada dentro de cada vertical slice: Isso depende da liderança e da organização do time, oo que pode ser uma grande vantagem. Você ganha a possibilidade de combinarr, por exemplo, que todas as funcionalidades sejam definidas com o mesmo padrão de projeto, como Clean Architecture, ou pode definir arquiteturas que façam sentido pra cada funcionalidade. Em alguns casos pequenos, pode fazer muito mais sentido usar apenas o bom e velho MVC. 2 - Muitas camadas, o que gera complexidade: A ideia é justamente o contrário. Você tem uma série de camadas coesas e mais simples. Você diminui bastante o problema de ter que transitar por vários diretórios diferentes pra ter que trabalhar com uma funcionalidade pequena. 3 - Aumenta o mix de tecnologias e diminui a manutenibilidade: Tendo cada feature mais bem separada, se a equipe for definida por funcionalidade, o overhead mental vai ser diminuído, porque cada um vai ter que trabalhar na verdade com uma menor variedade de soluções. Ao mesmo tempo, cada parte é muito coesa entre si e bem desacoplada das outras, o que melhora muito a manutenibilidade. Inclusive essa é a idea central muito mal aplicada do clean archtecture. O Bob Martin fala bastante do Screaming Architecture, em que na primeira batida de olho na estrutura de pastas, você saberia detalhes sobre o que a aplicação faz, não detalhes sobre onde ficam entidades, domínios, presenters, etc
Assunto bem legal com pouquíssimo conteúdo em português.
Acredito que esse seja o primeiro canal brasileiro de arquitetura a dar visibilidade de prós e contras pra essa estratégia.
Vlw por trazer o ponto de vista sobre a Vertical Slice
Massa demais Élix, muito obrigado pela sugestão e pela participação 👊🏻
Esse é um ótimo padrão para garantir os nossos empregos por mais alguns anos.
Pq vc pensa isso? Pelo q entendi, apenas se a equipe resolver seguir uma implementação mt diferente pra cada feature poderia causar problemas. Mas se toda feature tiver uma guideline (cotroller, service, dao) me parece ser mais fácil para integração de novos colaboradores e manutenção a longo prazo.
Nota: Estou apenas estudando o tema, nunca apliquei na prática, estou comentando com base em impressões pessoais e gostaria de saber outras visões.
Acho interessante uma abordagem de arquitetura hexagonal/onion/clean com o uso de Vertical Slicing dentro do adapter de interface, para aplicações com o UI complexo. A componentização ou separação por features é muito mais natural no frontend.
Posso utilizar uma Arquitetura Limpa + Vertical Slice? Tendo nossos projetos de Domain, Infrastructure? Por exemplo no C#.
Com certeza
nao entendi nada.
Ótimo vídeo como sempre, mas acabei não concordando muito com suas desvantagens. Você tratou o padrão como uma prática de transição apenas. A maioria dos problemas apresentados foram relacionadas às transições e refatorações em si e não à arquitetura.
1 - Confusão sobre qual organização deve ser usada dentro de cada vertical slice:
Isso depende da liderança e da organização do time, oo que pode ser uma grande vantagem. Você ganha a possibilidade de combinarr, por exemplo, que todas as funcionalidades sejam definidas com o mesmo padrão de projeto, como Clean Architecture, ou pode definir arquiteturas que façam sentido pra cada funcionalidade. Em alguns casos pequenos, pode fazer muito mais sentido usar apenas o bom e velho MVC.
2 - Muitas camadas, o que gera complexidade:
A ideia é justamente o contrário. Você tem uma série de camadas coesas e mais simples. Você diminui bastante o problema de ter que transitar por vários diretórios diferentes pra ter que trabalhar com uma funcionalidade pequena.
3 - Aumenta o mix de tecnologias e diminui a manutenibilidade:
Tendo cada feature mais bem separada, se a equipe for definida por funcionalidade, o overhead mental vai ser diminuído, porque cada um vai ter que trabalhar na verdade com uma menor variedade de soluções. Ao mesmo tempo, cada parte é muito coesa entre si e bem desacoplada das outras, o que melhora muito a manutenibilidade.
Inclusive essa é a idea central muito mal aplicada do clean archtecture. O Bob Martin fala bastante do Screaming Architecture, em que na primeira batida de olho na estrutura de pastas, você saberia detalhes sobre o que a aplicação faz, não detalhes sobre onde ficam entidades, domínios, presenters, etc
Muito obrigado pela participação Flávio 👊🏻