Uma dúvida comum e recorrente em minhas consultorias é “Como eu faço para manter a consistência de dados entre meus microsserviços?”. Embora essa seja uma questão justificada, entendo que ela revela um problema crítico para o desenho de arquitetura:

Não deveríamos começar um sistema planejando como os dados serão persistidos. Deveríamos pensar nas operações que precisaremos suportar.

Nesse post, tento apresentar um pouco melhor essa visão.

Para ver outros posts sobre microsserviços, acesse o guia de posts sobre este tema..

De onde vem essa obsessão pelos dados?

Honestamente, não sei dar uma razão precisa para isso. Mas, acredito fortemente que exista uma relação com o fato de, tradicionalmente, as pessoas pensarem nas estruturas dos bancos de dados relacionais por elas serem realmente difíceis de mexer mais tarde.

O problema de tentar desenhar a estrutura do banco de dados logo no início do projeto é que esse é precisamente o momento em que sabemos menos sobre os dados. (Ayende)

Por que pensar em operações é mais relevante?

No dia-a-dia, são as operações, e não os dados, que agregam valor para o negócio. Aliás, qualquer especialista de negócios vai ser muito mais assertivo descrevendo quais são as operações de negócio que o sistema deve suportar no lugar dos dados que ele deve manter.

Pense nisso: Ninguém compra um sistema pelo menu “cadastros”.

E sobre microsserviços…

Em microsserviços, faz mais sentido tentar pensar o sistema pelas operações que cada microsserviço irá suportar do que pelos dados que terá de manter.

Sistemas onde existe uma preocupação muito grande com dados, quando fracionados em serviços, acabam ficando como os “módulos” dos monolíticos, com bases separadas e dados potencialmente defasados.

Microsserviços não são módulos (pelo menos, não como concebemos tradicionalmente). Cuidado!

Pensar em operações nos ajuda a entender impactos

Outro dia, estava em um projeto onde uma das preocupações era como manter os “dados comuns” de uma tabela de produtos. Então perguntei:

– Quais são as operações de negócio que disparam a troca da unidade de medida de um produto, por exemplo?

Pessoal, surpreso, teve dificuldade para entender minha pergunta. Logo depois, teve dificuldade ainda maior para responder. Isso indica, geralmente, que o sistema, centrado em dados, está descolado da realidade do negócio. Mas… Fiz outra pergunta.

– Quais são os impactos de uma modificação da unidade de medida de um produto, feita no marketing, para a produção? E para o faturamento?

Obviamente, a troca da unidade de medida implica em uma série de ajustes na área produtiva de uma indústria! Há de se pensar em setup de máquinas, em embalagem, em estoque atual, … Ou seja, o menos importante é a alteração da unidade de medida em si, mas os impactos que isso ocasiona para as outras áreas.

Um efeito colateral interessante

Nesse mundo de devices com telas pequenas, ou dispositivos de entrada nem sempre tão ágeis, pensar em operações no lugar dos dados é um alívio para quem precisa pensar na UX.

Ninguém mais quer, e cada vez mais podemos ter, telas com centenas de campos.

Pense nos aplicativos modernos. Eles nos entregam operações, não cadastros!

Concluindo

Pensar em um sistema partindo dos dados que ele armazena e manipula é um erro básico insistentemente repetido em quase todas as organizações onde fui chamado para consultoria. Tenho crença de que seja uma herança dos bancos de dados relacionais, mas não acho que a culpa seja só deles.

Quando for criar um novo sistema, ou pensar em adotar microsserviços, comece pelas operações! Tudo fica mais fácil. Garanto que até mesmo a ideia de ter bases separadas para cada microsserviço vai lhe parecer menos assustadora.

Agradecimentos para Ricardo Alves. Nosso bate-papo motivou esse post.

6 Comentários
    1. Muito bom! Abriu a mente e aliviou um pouco a obsessão por dados, realmente pensar em operações torna a aplicação mais aderente.

  1. Elemar depois do DDD desapeguei do banco de dados. Mais ainda tem uma paranoia/obsessão por transação de banco de dados. por causa da questão de não ter perda de dados(acid) e junta com escalabilidade.

  2. Tá aí um tema que quero estudar bastante, e praticar. Pelo que entendi, a construção de um software com mais foco em operações, deixa o produto final mais adequado a necessidade do mundo real, com telas mais “clean”, que por consequencia vai reduzir a necessidade de treinamento/suporte.

  3. Show Elemar! Estava almoçando com uma turma de teste e análise na empresa onde trabalho e perguntei por onde começar no desenvolvimento de software. Banco ou software ? Um colega foi falando que era banco de dados e que não dava para pensar em um sistema sem modelar os dados primeiro. Tentei pelo meu conhecimento defender a idéia da melhor compreensão ao pensar no software, mas estes 3 minutos de leitura foi o suficiente para afirmar a idéia. Não que seja errado modelar o banco primeiro, mas é muito mais coerente e acertivo pensar nas operações.

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *