Eu acredito que não dá pra se construir um software de qualidade sem uma arquitetura de qualidade. Se sua arquitetura é ruim, você vai ter problemas no seu projeto mais cedo ou mais tarde, e vai te tomar um baita tempo pra consertar, sem falar na dor de cabeça e outras coisas.
O intuito desse post é falar justamente como eu faço a arquitetura dos projetos que eu trabalho, e como eu deixo as pastas e arquivos. Desenvolvo principalmente em Flutter, mas acredito que você possa se basear nessa arquitetura pra outros tipos de projetos, frameworks, linguagens, e por aí vai.
A arquitetura limpa
Se você já pesquisou sobre arquitetura de software com certeza já esbarrou na tal da clean architecture do Uncle Bob. Eu estudei bastante os princípios da clean architecture pra chegar na arquitetura que eu proponho neste artigo. Basicamente você divide o projeto em camadas e cada camada tem suas funções, atribuições, etc.
As camadas
Basicamente eu divido o projeto nas seguintes camadas: entidades, repositories, controllers, view respectivamente. Imagina que cada camada pode enxergar a si mesma e as anteriores. A camada de entidades só pode conversar entre si, e nunca as outras. A de repositories, a si mesma e a de entidades. E por aí em diante.
1. Entidades
Uma entidade seria uma representação de um dado ou objeto. Por exemplo, você pode ter uma entidade Usuario que seja um model com uns atributos tipo id, nome, cpf, endereço. Essa seria a representação do usuário e é a única função dessa entidade. Note que ela não pode depender de nenhuma outra camada. Ela também não tem fromJson nem toJson nela, pois isso seria função da segunda camada.
2. Repositories
Essa camada se divide em três partes: os repositório, os datasource e os DTO. Um repositório é onde você você busca e envia os dados da sua aplicação. Meio que as portas de entrada e saída. Um repositório sempre deve ser uma interface, que posteriormente você irá implementá-la em datasource. Um datasource (fonte de dados) é onde você implementa os repositories. Por exemplo, se você for trazer dados da api, você cria um repositório com os métodos que for usar e implementa na api_datasource por exemplo. No mesmo projeto, se quiser salvar alguma preferência do usuário (se quer tema escuro ou tamanho da fonte, por exemplo) pode implementar um preferencias_repository no local_datasource, como local_preferencias_repository. E por fim, os DTO (Data Transfer Object) são basicamente classes para você transitar dados de uma camada para outra, ou de um arquivo para outro, como parâmetros de telas e coisas nesse sentido.
3. Controllers
Talvez seja a camada mais complicada da aplicação. Vai ser onde fica as regras de negócios da sua aplicação. Validações, métodos, funções, parâmetros e todas essas coisas vão aqui. O controller pode ser um singleton na aplicação ou não.
4. View
A quarta e última camada, é basicamente a parte gráfica da aplicação que interage diretamente com o usuário. Eu divido ela em duas partes no Flutter: as screens e os widgets. As screens são as telas em si e os widgets são os componentes comuns usados em vários lugares da aplicação, como caixas de texto personalizadas, botões, e por aí vai.
Conclusão
Bom, essa foi a apresentação da arquitetura que eu uso nos meus projetos. Abaixo vou deixar um projeto exemplo para mostrar a arquitetura na prática, acho que ajudaria a ilustrar melhor tudo isso. Obrigado a todos que leram e qualquer coisa pode entrar em contato comigo!
Top comments (0)