O padrão BLoC na arquitetura limpa

No artigo anterior, vimos em que consiste o padrão BloC.

Como vimos, é um padrão bastante versátil e comentei que se encaixa bem com a Arquitetura Limpa.

Quando o padrão BloC não é suficiente

Inicialmente, o padrão BLoC foi apresentado para gerenciar a lógica de negócios de um aplicativo.

O contexto em que foi apresentado foi como uma solução para uma aplicação sem uma arquitetura definida que contém toda a lógica de negócio nos componentes da interface.

Dessa forma, a lógica de negócios do aplicativo pode ser reutilizada entre suas versões de diferentes tecnologias.

Em aplicativos bastante complexos, a lógica é um conceito amplo porque, dependendo do aplicativo, pode incluir:

• A lógica de apresentação é tudo o que está relacionado à interface do usuário, como formatar os dados conforme a necessidade da interface, decidir o que é visível e o que não é, decidir se barras de progresso ou mensagens para o usuário devem ser exibidas e quais informações mostrar.
• A lógica de negócios de negócios representa as regras de negócios que são independentes do aplicativo e que seriam válidas na empresa mesmo que o aplicativo não existisse como método de automação.
• A lógica de negócios da aplicação, representa os casos de uso da aplicação, é a lógica encarregada de coordenar quais solicitações devem ser feitas à fonte de dados, bem como coordenar a interação entre as diferentes regras de negócio do negócio.
• Lógica de dados, quando em uma aplicação existem várias fontes de dados como API e cache de banco de dados, esta lógica se encarrega de coordenar quando chamar uma fonte de dados ou outra.

Centralizar toda essa lógica em BLoCs pode ser um exagero e acabamos tendo classes muito grandes e difíceis de manter.

Nesses casos, usar a Arquitetura Limpa ajuda a ter um aplicativo mais testável e sustentável.

Arquitetura Limpa para o resgate

Com a Arquitetura Limpa, o que vamos fazer é dividir as responsabilidades que vimos antes em diferentes componentes, em vez de centralizá-las nos BloCs.

Com isso obtemos uma série de vantagens:

• Escalabilidade ou capacidade de suportar melhor as mudanças futuras.
• Testabilidade, poderemos testar cada responsabilidade separadamente.
• Independência de frameworks, UI e banco de dados, respeitando a regra de dependência da lógica de negócios da aplicação e da lógica de negócios, que é o núcleo da aplicação e que são as que menos mudam com o tempo, não são desajustadas de bibliotecas e estruturas.

Ao usar uma arquitetura limpa, vamos ver quem assume cada uma das responsabilidades.

• lógica de apresentação, quando usamos Clean Architecture, o padrão BLoC se ajusta como um padrão de apresentação, assim como controladores em MVC, apresentadores em MVP ou modelos de visualização em MVVM.
• lógica de negócios de negócios, seriam as entidades que assumiriam essa responsabilidade, validando suas invariantes por meio de regras de negócios.
• lógica de negócios do aplicativo, são os casos de uso que coordenarão as ações necessárias para cada cenário do aplicativo. Coordenar as chamadas à camada de dados necessária e a interação entre as entidades.
• lógica de dados, os repositórios assumem a lógica de saber qual fonte de dados chamar.

Lembre-se de que a chave para a Arquitetura Limpa é a regra de dependência. Todas as dependências devem apontar para dentro e não pode haver nenhum círculo interno apontando para um externo.

O mais importante é que todas as dependências devem ir para o domínio e o domínio não deve apontar para nada externo.

Observe que o padrão BLoC permanece como um padrão de camada de apresentação.

BloC visto como um padrão de apresentação

Usando a Arquitetura Limpa, um BloC toma o lugar dos adaptadores de interface como intermediário entre as visualizações e o domínio.

Um padrão de apresentação no Clean Architecture se destina a gerenciar a lógica da camada de apresentação.

Lembremos que BLoC significa Business Logic Component, mas neste contexto faria mais sentido que se chamasse PLoC (Presentarion Logic Component) ou RPloC (Reactive Presentation Logic Component) ou simplesmente apresentador.

Um padrão de apresentação é dividido em View, Model e um terceiro componente que fica entre os dois.

O modelo corresponde, neste caso, ao domínio (casos de uso, limites e entidades).

BLoC seria este terceiro componente e tem vários objetivos:

• É um intermediário entre a visão e o domínio.
• É um adaptador.
• Decida o que acontece na interface do usuário.

É um intermediário entre a visão e o domínio

Toda a comunicação entre a visualização e o domínio será feita através do BLoC.

No caso do BloC, como vimos no artigo anterior, ele conta com o padrão do observador para se comunicar com uma visão ou várias se compartilharem estados.

Quando a view deseja se comunicar com o modelo (domínio e dados), isso será feito através do BloC por meio de ações ou eventos.

Lembre-se que, como vimos no artigo anterior, podemos ter várias estratégias dependendo da implementação do padrão BloC que usamos, o que implica ter uma ou mais entradas.

Por um lado, podemos ter vários métodos no BloC que representam as diferentes ações que podem ser feitas.

Podemos ter um único método, por exemplo denominado despacho, o que significa que devemos ter uma hierarquia de eventos que podem ser executados para que no método de despacho possamos saber a ação que a visão deseja fazer.

Por sua vez, temos uma entrada ou duas, eles podem ser métodos ou observáveis ​​se quisermos fazer as entradas também reativas.

É um adaptador

Representa um adaptador que transforma as informações compreendidas pela interface do usuário nas necessidades do domínio de nosso aplicativo.

Ele também transforma as informações da forma como nosso domínio as entende e como a interface do usuário precisa delas.

Decida o que acontece na interface do usuário

Participe parcial ou totalmente das decisões sobre o que acontece na interface do usuário.

O BloC é responsável por comunicar quando a interface do usuário deve ser atualizada. Por meio do padrão observador, ele se encarrega de comunicar à visão ou às visões inscritas em seu status quando precisam ser atualizadas.

O BloC decidirá se mostra uma barra de progresso ou não, se mostra erros ou outras mensagens ao usuário e quais dados devem ser apresentados ao usuário na interface do usuário.

Essas decisões serão tomadas atualizando o estado observável com base nas ações ou eventos recebidos das visualizações.

Lembre-se que como vimos no artigo anterior, teremos um estado ou vários observáveis ​​dependendo da implementação do padrão BLoC que usarmos, o que implica em ter uma ou mais saídas.

Conclusões

Neste artigo, vimos como o padrão BloC e Clean Architecture se encaixam.

Como vimos, eles se encaixam perfeitamente se virmos o padrão BLoC como um padrão de apresentação, como já acontece com MVC, MVP ou MVVM.

Em artigos futuros, veremos exemplos aplicados a Flutter e ReactJS.