Google slides: https://docs.google.com/presentation/d/1bRYoDVn7S9JawcK7ycQhv6LggTLnb-tQMRWhtXMXpWc/edit?usp=sharing
Já se deparou com essas perguntas:
1. Como refletir regras de negócios em uma aplicação Rails?
2. Como garantir que um padrão de dev seja facilmente absorvido e mantido pelo time?
Todo time de dev, empresa de tecnologia precisa equilibrar a relação entre qualidade e velocidade em prol das entregas.
E infelizmente, é muito comum muitos sacrificarem qualidade porque o time investiu tempo estruturando o projeto mas perdeu o prazo da entrega, e por conta disso passou a fazer do jeito que dá e então começou a perder o prazo novamente por conta do codebase virar uma zona.
Dado o contexto acima, gostaria de compartilhar com vocês a importância de se entender os casos de uso da sua empresa/produto e como implementá-los de maneira prática e padronizada.
E porque service objects podem se tornar um problema em suas aplicações da sua natureza generalista (é muito comum ouvir: se não vai na model, controller... adiciona em um service object!).
Tópicos que serão abordados:
- Fat controllers & Fat models
- Service Objects
- Domain objects
- Use cases
- Abstrações existente na comunidade:
- Interactor
- Micro::Case (https://github.com/serradura/u-case)
- Como estruturar aplicações Rails fazendo uso desses conceitos.