Quando escrevi o Patterns of Enterprise Application Architecture, eu cunhei o que chamei de Primeira Lei do Design de Objetos Distribuídos: "não distribuir seus objetos". Nos últimos meses tem havido um grande interesse em microsserviços, o que levou algumas pessoas a perguntarem se os microsserviços não desrespeitam essa lei e, se é assim, por que eu sou a favor deles?
É importante notar que, nessa primeira declaração da lei, eu usei a frase "objetos distribuídos". Isso reflete uma ideia que esteve bastante em voga nos anos 90 e no início dos anos 00s, mas que desde então tem caído em desuso (com razão). A ideia de objetos distribuídos é que você poderia projetar objetos e optar por usar esses mesmos objetos ou em processo ou remotamente, onde remotamente pode significar um outro processo na mesma máquina ou em uma máquina diferente. Um middleware inteligente, como DCOM ou uma implementação CORBA, iria lidar com a distinção em processo/remoto para que o sistema pudesse ser escrito e você pudesse dividi-lo em processos independentemente de como o aplicativo foi projetado.
Minha objeção à noção de objetos distribuídos foi que embora você possa encapsular muitas coisas nos limites do objeto, você não pode encapsular a distinção remoto/em processo. Uma chamada de função em processo é rápida e sempre bem-sucedida (em que todas as exceções são devido ao aplicativo, não devido ao simples fato de fazer a chamada). Chamadas remotas, no entanto, são ordens de magnitude mais lenta, e sempre há uma chance de que a chamada falhe devido a uma falha no processo remoto ou a conexão.
A consequência dessa diferença é que suas diretrizes para APIs são diferentes. Chamadas em processo podem ser granulares, se você quiser 100 preços de produtos e disponibilidades, você pode facilmente fazer 100 chamadas para a função de preço do produto e outras 100 para as disponibilidades. Mas se essa função é uma chamada remota, é geralmente melhor que você envie tudo isso em uma única chamada que pede todos os 100 os preços e disponibilidades de uma só vez. O resultado é uma interface muito diferente do seu objeto de produto. Consequentemente, você não pode ter a mesma classe (que é principalmente sobre interface) e usá-la de forma transparente em processo ou remotamente.
Os defensores de microsserviços com quem falei estão muito conscientes dessa distinção, e eu não ouvi nenhum deles falar sobre transparência em processo/remota. Então, eles não estão tentando fazer o que os objetos distribuídos estavam tentando fazer e, portanto, não violam a primeira lei. Em vez disso, defendem interações de maiores com documentos usando HTTP ou mensagens leves.
Então, em essência, não há contradição entre o meu ponto de vista sobre os objetos distribuídos e os defensores de microsserviços. Apesar deste não-conflito essencial, hoje há uma outra pergunta que está implorando para ser feita. Microsserviços implicam pequenas unidades distribuídas que se comunicam através de conexões remotas muito mais do que um monolito faria. Isso não viola o espírito da primeira lei, mesmo sem quebrá-la?
Para ler todo o artigo, clique aqui: : martinfowler.com/articles/distributed-objects-microservices.html.
Aviso: As afirmações e opiniões expressas neste artigo são de responsabilidade de quem o assina, e não necessariamente refletem as posições da Thoughtworks.