Ou seja, sistemas que acumulam tanto as dificuldades de sistemas distribuídos quanto as de monólitos que rodam em um único processo. Tudo isso, sem quaisquer vantagens para os times técnicos tampouco para o negócio.
Sabemos, com certeza, que estamos frente a um monólito distribuído quando todo deploy precisa ser do “sistema inteiro”, mesmo que sua composição seja serviços rodando em processos independentes.
Também há boas chances de estarmos lidando com um monólito distribuído quando há alto changing coupling. Ou seja, quando qualquer modificação em um serviço implica modificações em outros, mesmo que estes estejam em repositórios diferentes.
Monólitos distribuídos emergem rapidamente em arquiteturas com “serviços de dados”, geralmente produzidos tentativas bem-intencionadas de implementar REST, mas que não passam de “camadas sofisticadas” de persistência rodando em processos separados.
Também são monólitos distribuídos emergentes aqueles sistemas com frontend em repositório apartado daquele(s) onde está/estão o(s) serviço(s) com a lógica de negócio, mas onde todos os desenvolvedores precisam manter clones de todos os repositórios em suas máquinas e pelo menos duas instâncias da IDE abertas para “depurar o todo”.
Sistemas monolíticos distribuídos são efeito colateral da prática descuidada das disciplinas de arquitetura, não dedicando tempo e atenção suficientes na delimitação dos contextos, resultando na baixa coesão das funcionalidades para o negócio.
O antídoto para os monolíticos distribuídos passa pela resistência a “fragmentação” exagerada, que só aumenta a complexidade e a quantidade de código repetido. É essencial considerar a coesão sobretudo das funcionalidades.
Não podemos ignorar que uma das principais justificativas para a decomposição de um sistema em serviços é transferir parte da complexidade das atividades de desenvolvimento para a operação, onde poderá ser mitigada com automação. Se a atividade de desenvolvimento não fica mais fácil, adicinou-se apenas complexidade desnecessária e custos não justificados.
Em tempos onde todo mundo está ansioso para desenvolver sistemas com microsserviços, é necessário cuidado redobrado para não acabar “trazendo ao mundo” mais um monolítico distribuído. Click To Tweet
Muito bom os artigos de vocês, estou sempre lendo e sempre tomando uma porrada diferente. Faz total sentido o que diz acima, mas eu trabalho com angular ++ e dotnet core, tenho q trabalhar no back e no front pq só existe eu na empresa onde trabalho. Quase sempre estou com 2 vscode abertos, as vezes o ssms tambem. Eu gostei muito mais de trabalhar assim, pois conseguir ficar mais organizado e as vezes me sinto até mais produtivo, pq consigo dar uma focada em uma stack só durante um tempo. Sei que o foco do artigo é criticar a complexidade desnecessária. Mas qual seria a alternativa pra trabalhar com APIs e Spas, sem ter 2 repositórios diferentes? Um abraço, parabéns pelos artigos mais uma vez
Acaba que com a sua stack até que dá pra trabalhar no mesmo repositório, visto que ambas se desenvolve com a mesma IDE. Mais o maior problema é a complexidade de ter o código da mesma aplicação em dois repositórios separados, pois aumenta a possibilidade de se fazer uma implementação em um repo e deixar de fazer no outro repo.
Além disso o trackeamento das alterações é único quando temos um repositório apenas para front e back.
Exatamente por esse e alguns outros motivos que defendo não seguir uma determinada proposta de engenharia, arquitetura ou partner como verdade absoluta. Mas defendo ao mesmo tempo que é prudente estar sempre o mais próximo possível de tender a elas. E isso se conquista com capacidade abstração e construção de domínios com facilidade na compreensão além de alta diligência.
Eu prefiro manter em repositórios separados. Entendo que existe um acoplamento e muitos commits serão “redundantes”, mas também existem muitas preocupações no front que não é nada acomplada com o back sendo assim, para mim, projeto diferentes.
Olá Elemar, os links para eximia.tech citados estão indisponíveis, eles vão ser migrados para insights?