Arquitetura Limpa: o bom, o ruim e o feio

Uma abordagem diferente, usando relatos das pessoas da comunidade de tecnologia para entender como a arquitetura limpa funciona em produção - e se funciona bem em todos os casos.

Transcript

1. Arquitetura limpa: o bom, o ruim e o feio
2. Na teoria, todo conceito é incrível e funciona
3. Arquitetura de sistemas ou Arquitetura de código?
4. Algumas das promessas da Clean Architecture: - Manutenibilidade - Testabilidade - Desacoplamento - Separação de contextos - Inversão de dependência
5. Desacoplamento, não doutrinação DEJAMIR GIANELLI Um dos principais males do desenvolvimento de software é o alto acoplamento, e que um software com muito acoplamento entre diversas camadas e conceitos pode, a médio e longo prazo virar um Frankenstein difícil de se manter, testar e evoluir. A separação entre as camadas de negócio, aplicação e infraestrutura e a direção de dependência no final das contas tem o propósito de reduzir tal acoplamento.
6. S.O.L.I.D. Design Patterns Desacoplamento, não doutrinação
7. The good, the bad and the ugly
8. The good, the bad and the ugly
9. The good, the bad and the ugly
10. The good, the bad and the ugly
11. DEJAMIR GIANELLI Conversar sobre arquitetura de software falando de desacoplamento e componentização me parece muito mais interessante do que citar nomes, padrões e terminologias da moda que acabam soando mais como algum tipo de doutrinação na qual se você não seguir à risca tudo que está em um determinado livro você está cometendo uma blasfêmia
12. Alguns afirmam que a Arquitetura Limpa é overengineering Clean Architecture with Robert Martin (a.k.a. Uncle Bob) | theWiseDev-chat
13. Tomato Architecture
14. Tomato Architecture Não há absolutamente nada de novo na Tomato Architecture. São apenas algumas boas práticas de codificação e decisões arquitetônicas para manter as coisas simples e trazer de volta um pouco de sanidade para evitar o excesso de engenharia. Novamente, “Tomato” na “Arquitetura do Tomate” não significa nada. Assim como “Hexagon” em “Hexagonal Architecture” não significa nada. Não se prenda muito ao nome.
15. Tomato Architecture Pense no que é melhor para o seu software ao invés de seguir cegamente as sugestões de pessoas populares. Esforce-se para manter as coisas simples em vez de exagerar na solução, adivinhando os requisitos para a próxima década. Escolha uma tecnologia e adote-a em vez de criar abstrações com capacidade de substituição em mente. Certifique-se de que sua solução esteja funcionando como um todo, não apenas em unidades individuais. Princípios chave
16. Evolução da arquitetura do lado de back-end (AND-layered, DDD, Hexagonal, Onion, Clean Architecture)
17. Referencias: https://www.oreilly.com/library/view/fundamentals-of-software/9781492043447/ https://www.linkedin.com/pulse/por-que-estou-tentando-n%C3%A3o-fazer-mais-refer%C3%AAncia-clean-gianelli/ entrevista: https://twitter.com/otaviolemos/status/1677272857599000577 https://twitter.com/sivalabs/status/1661037389534617600 https://twitter.com/mjovanovictech/status/1685531738435387392 https://twitter.com/mjovanovictech/status/1684806975899525120 https://twitter.com/hugaomarques/status/1681130125163626496 https://medium.com/@iamprovidence/backend-side-architecture-evolution-n-layered-ddd-hexagon-onion-clean-architecture-643d72444ce4 https://github.com/sivaprasadreddy/tomato-architecture https://isaiascuvula.medium.com/flutter-clean-architecture-2837583ed5c0 https://youtu.be/ONj4zvLtmpA https://twitter.com/mjovanovictech/status/1685970125579603968 https://twitter.com/maciejwalkowiak/status/1662502738058440705