Domando o Monólito Rails: Como +300 Engenheiros Entregam Juntos

Transcript

1. Domando o monólito Rails: Como +300 Engenheiros Entregam Juntos Heitor Almeida | GURU - SP 71
2. Quem sou eu - Iniciei com ruby/rails em 2016 e nunca mais troquei a stack - Comecei a trabalhar pro exterior em 2021 - Em 2023 entrei como Sr Software Engineer na Housecall Pro
3. Quem sou eu
4. Quem sou eu
5. O que é a Housecall Pro - Empresa de tecnologia nos EUA - SaaS para prestadores de serviços - Handyman - Encanador - HVAC (Heating, Ventilation and Air Conditioning) - Etc. - Dezenas de milhares de clientes ativos
7. Stack
12. Dificuldades de navegar uma codebase tão grande - Onde começo? - Preciso entender tudo? - Divisão por componentes (domínios) - Focar nos componentes da squad - DDD
13. DDD - Discagem Direta a Distância - 43 - Londrina - PR - 53 - Pelotas - RS - 94 - Parauapebas - PA - 31 - Itabira - MG - 11 - São Paulo - SP
14. DDD (Domain Driven Design) - Centralizar o desenvolvimento em torno de um modelo de domínio rico e evolutivo que capture a lógica de negócio - Enfatiza a criação de uma Linguagem Ubíqua que incorpora terminologia de domínio diretamente nos sistemas - Introduz conceitos de design estratégico como - Contextos Delimitados (Bounded Contexts) - Classificação de objetos - Entities - Value Objects - Service Objects
20. Codeowners
21. Codeowners
22. Codeowners
25. Problemas - Não temos um jeito de rastrear dependências entre os componentes - Sem isso, é difícil de pensar em iniciativas entre squads e iniciativas entre componentes - Dependentes de conhecimento organizacional e alguma documentação sobre regras - Criar documentação demanda muito tempo, como criar/recriar mapas de contexto - Essa demora atrapalha o início de discussões sobre opções para soluções de problemas
32. Como estamos usando packwerk na empresa - Todo app/component/ vai ter - package_todo.yml - package.yml - Adoção gradual - CI check para novas ofensas não serem adicionadas
34. Futuro - Eliminar todos/melhorar definições nos pacotes - Adoção obrigatória do packwerk feita neste trimestre - Compartilhamento de conhecimento interno sobre como estruturar melhor os componentes
35. Conclusões - Packwerk não é bala de prata - Não adicionem em seus projetos só por adicionar - Separação de domínios faz com que squads consigam entregar funcionalidades sem interferir com outros domínios - Uso de API e contratos para comunicação
36. Obrigado! Perguntas?
37. Referências - https://www.oreilly.com/library/view/domain-driven-design-tackling/032112521 5/ - https://martinfowler.com/bliki/DomainDrivenDesign.html - https://martinfowler.com/bliki/BoundedContext.html - https://github.com/shopify/packwerk - https://www.youtube.com/watch?v=olxoNDBp6Rg