Proposta de Arquitetura Limpa para o Dart/Flutter
Podemos dizer que uma arquitetura limpa pode definir o futuro do seu projeto, sabendo disso, devemos tê-la como objeto de estudo constante para que assim saibamos onde, quando e como aplicá-la.
Para essa proposta nos baseamos nas camadas da Arquitetura Limpa proposta por Robert C. Martin no livro “Arquitetura Limpa: O Guia do Artesão para Estrutura e Design de Software”.
Robert C. Martin conclui que uma arquitetura deve conter pelo menos 4 camadas principais e independentes para ser considerada “limpa”, são elas:
- Regras de Negócio Corporativas
- Regras de Negócio da Aplicação
- Adaptadores de Interface
- Frameworks & Drivers (Externos)
São as regras de negócio cruciais para a sua aplicação, são representadas por modelos de dados denominado "Entidades", essa camada tem as regras mais sensíveis de um sistema, por isso ela está no topo das camadas. Uma "Entidade" deve ser pura, ou seja, não deve conhecer nenhuma outra camada, porém é conhecida pelas outras camadas.
São as regras que só o computador pode executar, aqui temos uma representação de comandos chamados de "Casos de Uso", e basicamente representam as ações que um usuário pode fazer na aplicação.
Um "Caso de Uso" conhece apenas as Entidades, porém não sabe nada sobre as implementações das camadas de mais baixo nível.
Se um "Caso de Uso" precisar acessar uma camada superior, deverá fazê-lo por meio de contratos definidos por uma interface, seguindo o “Princípio de Inversão de Dependências” do SOLID.
Essa camada é responsável por “dar suporte” para as camadas mais altas (Regras de Negócios) convertendo os dados externos em um formato que cumpra os contratos de interface definidos pelas Regras de Negócios.
Todas as abstrações feitas pelas camadas mais altas foram para aumentar a facilidade do plug & play dos artefatos externos como um banco de dados ou uma interface gráfica.
Essa camada normalmente sofre muitas modificações, porém com uma arquitetura limpa aplicada isso pode ser completamente indolor e segura para a sua regra de negócio.
Podemos então trocar uma API REST por outra em GraphQL sem afetar suas regras de negócio. Poderemos também trocar a interface gráfica completamente ou até mesmo trocar o Flutter pelo AngularDart e mesmo assim as Regras de Negócio ficarão funcionais!
Dado as descrições iremos apresentar a proposta de Arquitetura Limpa da Flutterando, a “Clean Dart”.
Usando o Flutter como exemplo teremos então quatro camadas mantendo a “Arquitetura de Plugin”, com foco principal no Domínio da Aplicação, camada esta que hospeda as 2 Regras de Negócio principais, estamos falando das Entidades e dos Casos de Uso.
A proposta de Arquitetura se propõe a desacoplar as camadas mais externas e preservar a Regra de Negócio.
A Camada Presenter fica responsável por declarar as entradas, saídas e interações da aplicação.
Usando o Flutter como exemplo, hospedaremos os Widgets, Pages e também Alguma Gerência de Estado, já no backend como exemplo, seria nesta camada onde colocaríamos os Handlers ou Commands da nossa API.
A camada de Domain hospedará as Regras de Negócio Corporativa(Entity) e da Aplicação(Usecase).
Nossas Entidades devem ser objetos simples podendo conter regras de validação dos seus dados por meio de funções ou ValueObjects. A Entidade não deve usar nenhum objeto das outras camadas.
Os Casos de Uso devem executar a lógica necessária para resolver o problema. Se o Caso de Uso precisar de algum acesso externo então esse acesso deve ser feito por meio de contratos de interface que serão implementados em uma camada de mais baixo nível.
A camada Domain deve ser responsável apenas pela execução da lógica de negócio, não deve haver implementações de outros objetos como Repositories ou Services dentro do Domain.
Tomando um Repository como exemplo, teremos que ter apenas o contrato de interfaces(Abstrações) e a responsabilidade de implementação desse objeto deverá ser repassado a outra camada mais baixa.
Esta camada dá suporte a camada Domain implementando suas interfaces. Para isso, adapta os dados externos para que possa cumprir os contratos do domínio.
Muito provavelmente nessa camada iremos implementar alguma interface de um Repository ou Services que pode ou não depender de dados externos como uma API ou acesso a algum Hardware como por exemplo Bluetooth.
Para que o Repository possa processar e adaptar os dados externos devemos criar contratos para esses serviços visando passar a responsabilidade de implementação para a camada mais baixa da nossa arquitetura.
Como sugestão, iremos criar objetos de DataSource quando quisermos acessar um dado externo, uma BaaS como Firebase ou um Cache Local usando SQLite por exemplo. Outra sugestão seria criar objetos denominados Drivers para interfacear a comunicação com algum Hardware do dispositivo.
Os acessos externos como Datasources e Drivers devem ser implementados por outra camada, ficando apenas os Contratos de Interface nesta camada de Infra.
Aqui começaremos a implementar os acessos externos e que dependem de um hardware, package ou acesso muito específico.
Basicamente a camada External deve conter tudo aquilo que terá grandes chances de ser alterado sem que o programador possa intervir diretamente no projeto.
No Flutter por exemplo, para cache local usamos o SharedPreferences, mas talvez em alguma estágio do projeto a implementação do SharedPreferences não seja mais suficiente para a aplicação e deve ser substituída por outro package como Hive, nesse ponto a única coisa que precisamos fazer é criar uma nova classe, implementando o Contrato esperado pela camada mais alta (que seria a Infra) e implementarmos a lógica usando o Hive.
Um outro exemplo prático seria pensar em um login com Firebase Auth, porém outro produto deseja utilizar um outro provider de autenticação. Bastaria apenas implementar um datasource baseado no outro provider e “Inverter a Dependência” substituindo a implementação do Firebase pela nova quando for necessário.
Os Datasources devem se preocupar apenas em “descobrir” os dados externos e enviar para a camada de Infra para serem tratados.
Da mesma forma os objetos Drivers devem apenas retornar as informações solicitadas sobre o Hardware do Device e não devem fazer tratamento fora ao que lhe foi solicitado no contrato.
Quando for desenvolver comece a pensar por camada, não devemos nos preocupar com o que tem na camada de Presenter ou External por exemplo. Se pensarmos nas camadas mais externas podemos acabar nos orientando (erroneamente) por essas camadas. Assim, devemos nos acostumar a desenvolver camada por camada, de dentro para fora e não ao contrário.
Talvez no começo da sua jornada "Limpa" algumas camadas possam parecer "sem utilidade", isso acontece quando nossa mente ainda não está Pensando em Camadas (ou porque sua Regra de Negócio é simples demais para isso)
É muito comum os desenvolvedores criarem primeiro as suas Views para que então possam "testar" as Regras de Negócio. Mas nós já temos uma ferramenta própria para isso e um lugar dedicado para armazenar esses testes.
Desenvolver de forma "limpa" está em total sinergia com o TDD(Test Driven Development) pois a camada de Presenter será uma das últimas coisas que iremos pensar no desenvolvimento da nossa feature.
"É melhor deixar uma Exception acontecer do que tratar um erro de forma genérica"... Uma boa dica é usar alguma classe que nos obrigue a tratar os erros como o Either do pacote dartz.
Either é uma classe que pode receber dois tipos de dados, um Left (para quando enviar o erro) e o Right(para enviar o dado esperado). Isso também diminui muito a necessidade de realizar um tratamento manual de erro com try catch em camadas mais superiores como Presenter.
Algumas vezes você poderá ter um UseCase muito simples, que apenas repassa para o Repository, como por exemplo em um CRUD onde você apenas precisa validar se a informação está chegando da maneira correta e repassar para o Repository fazer seu trabalho.
Parece estranho você ter uma classe com um método que faz somente a validação dos dados e repassa para outra classe, porém você verá a grande utilidade disso no momento de uma manutenção. Pois muitas vezes o UseCase pode nascer pequeno mas em um futuro próximo ele pode ganhar corpo.
Um exemplo disso é a utilização do Firebase, o package do Firebase te retornar uma Stream que você pode muito bem colocar ele direto na sua View, porém se um dia você quiser remover o firebase do seu projeto, você terá que reconstruir toda sua tela ou pior todo seu projeto.
Sendo assim não caia na tentação de chamar o Repository direto do Controller ou mesmo plugar o Firebase direto na sua View, além de infringir as regras da arquitetura, você irá se arrepender em um futuro próximo.
Apreciamos o seu feedback! Se concorda com a proposta de Arquitetura Limpa "Clean Dart", deixe uma Star neste repositório. Uma Star é o mesmo que assinar um "manifesto limpo" concordando com essa proposta.
Estamos abertos a sugestões e melhorias na documentação! Faça isso por meio das issues, nossa equipe ficará muito contente com seu interesse em melhorar essa ferramenta para a comunidade.
Sinta-se a vontade para abrir um PR com correções na documentação dessa proposta.
- Clean Dart Login with Firebase, MobX and Modular
- Clean Dart Github Search with BLoC and Modular
- Clean Dart Github Search with MobX and Modular
- Clean Dart Github Search with Flutter Command
- Clean Dart Github - Path dependency with State Managers approaches
- Chat WebSocket with Get_It and Cubit
- Movie App With MicroApps, Modular and Flutter_Triple
- Clean Dart Pokedex with BLoC and Modular