🇧🇷 Porque armazenar Agregados com NoSQL ?

Com o movimento recente no uso de bancos de dados não relacionais, muitas opções de armazenamento de dados ficaram em evidência deixando o ambiente um tanto confuso ao decidir o que usar.

Decidir qual melhor forma de armazenar o estado de seus agregados e entidades sempre dependerá da necessidade do projeto, mas não podemos ficar distantes de sempre pensar na melhor opção e balancear os prós e contras.

Gostaria de deixar uma reflexão sobre o uso NoSQL e a persistência de Aggregates, talvez ela possa ajudar na decisão da sua arquitetura.

Para nivelarmos os conceitos, segundo Martin Fowler, um agregado é agrupador de objetos do domínio, que podem ser tratados como uma unidade.

Quero iniciar a reflexão com a persistência de bancos de dados relacionais, ressaltando que você terá que diluir o seu modelo de negócios em tabelas, colunas e relacionamentos. Com esse tipo de persistência, você sempre terá um esforço de infraestrutura para realizar a conversão entre um linhas de um banco de dados e os objetos do seu domínio, mesmo que você faça o uso de um ORM. Também é muito comum fazer o uso de design patterns para transformar os seus dados em um objeto relevante no seu domínio, como é o caso do Factory.

Abaixo segue uma imagem do Marin Fowler que ilustra muito bem essa complexidade.

Abstração de tabelas de um agregado “Pedido” (AggregateOrientedDatabase)

Com isso conseguimos levantar três passos para modelar um sistema com base de dados relacional: Criar tabelas e relacionamentos, definir a estratégia de recuperar os dados persistidos, definir estratégia de conversão do modelo relacional para o seu modelo de domínio.

Por outro lado, bancos de dados NoSQL oferecem uma forma mais livre e maleável de armazenar e recuperar seus dados, devido a sua simplicidade de armazenamento em chave/valor.

Existem vários produtos no mercado que implementam essa ideia, com pequenas variações, mas todos compartilham o mesmo conceito: Armazenamento de documentos (geralmente JSON) identificados por uma chave.

Esse modelo é ótimo para aplicações pois o armazenamento/recuperação dos dados é feita de forma nativa na maioria das linguagens, serializando o estado do agregado em JSON e convertendo de JSON para objetos.

Outro aspecto importante dessa abordagem é a escalabilidade proporcionada ao seu negócio, devido o modelo de armazenamento que pode ser distribuído em clusters de processamento. A IBM tem um ótimo artigo bem detalhado sobre esse aspecto, incluindo vários players do mercado, que pode também ajudar a uma decisão no seu modelo.

Os efeitos colaterais desse modelo estão na forma de leitura desse dado, pois se olharmos para uma coleção de “Pedidos de Vendas” e precisarmos saber todos os pedidos em um determinado dia, ou todos os pedidos com valor total maior do que US$ 100, não teríamos uma chave bem definida para tais consultas e acabaríamos esbarrando em um “full table scan” nas consultas.

O exemplo dado acima, mostra perguntas analíticas em cima dos dados, nesse caso, tais perguntas podem ser respondidas através de uma base de dados analítica, usando Data Warehouses. Para o lado transacional, apenas ficariam ações transacionais, tais como, recuperar um pedido de venda, mudar o status, cancelar, etc.

Em fim, parece bem razoável o uso de NoSQL para guardar o estado dos seus agregados, devido ao baixo custo de manutenção, escalabilidade, facilidade de implementação. A única restrição está na forma em que você vai formular as perguntas ao seu modelo de dados.

Se há algum lado que não foi coberto nessa reflexão e que você acha importante compartilhar, por favor, deixe um comentário contribuindo para a discussão.

Esse artigo também está disponível em Inglês.