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.
