Resumo Executivo

Mateus Miranda de Frias; Ariel Da Silva Dias

Resumo elaborado pela ferramenta ResumeAI, solução de inteligência artificial desenvolvida pelo Instituto Pecege voltada à síntese e redação.

A transformação digital e a crescente demanda por sistemas de software flexíveis e capazes de sustentar inovações aceleradas têm impulsionado organizações a buscarem a modernização de suas infraestruturas legadas. Sistemas construídos sob a arquitetura monolítica, embora tenham sido a norma por décadas devido à sua simplicidade inicial de construção e implantação, frequentemente enfrentam desafios críticos à medida que evoluem. O crescimento das funcionalidades e da base de código nesses sistemas resulta em alto acoplamento, dificuldades de escalabilidade e ciclos de teste e publicação excessivamente lentos (Kalske, 2017). Diante desse cenário, a arquitetura de microsserviços surge como uma alternativa modular, permitindo a organização de capacidades de negócio de forma granular e independente (Megargel, Shankararaman e Walker, 2020). Esse estilo arquitetural propõe a divisão de uma aplicação em serviços autônomos que operam em processos próprios e se comunicam por mecanismos leves, facilitando a manutenção e a evolução tecnológica (Fowler, 2014).

A adoção de microsserviços, contudo, não é isenta de complexidades. A transição de um monólito para uma estrutura distribuída exige mudanças profundas na infraestrutura e na cultura das equipes de desenvolvimento, especialmente no que tange à garantia de consistência de dados e à gestão da comunicação entre serviços (Fowler, 2014). Um dos maiores obstáculos nesse processo reside na etapa de decomposição, ou seja, na definição de como o sistema original deve ser fragmentado. A seleção de microsserviços candidatos é uma tarefa frequentemente realizada de forma manual e subjetiva, o que pode elevar a complexidade técnica e resultar em partições inadequadas (Chen, Li e Li, 2017). Decisões equivocadas sobre a granularidade dos serviços impactam diretamente atributos de qualidade como desempenho e testabilidade, tornando o processo de migração custoso no longo prazo (Li, Zhang e Jia, 2019).

Apesar da popularidade de diversos frameworks de migração, o campo de estudo sobre métodos de decomposição ainda se encontra em estágio preliminar, carecendo de dados integrados que comparem a eficácia de diferentes abordagens em cenários práticos (Abgaz et al., 2023). A ausência de métricas claras para avaliar os microsserviços candidatos após a decomposição dificulta a tomada de decisão por parte dos arquitetos de software. Nesse contexto, torna-se fundamental analisar técnicas que alinhem a arquitetura às necessidades de negócio, garantindo alta coesão e baixo acoplamento. O Design Orientado a Domínio destaca-se como uma das técnicas mais referenciadas, pois busca orientar os limites de cada serviço por meio de capacidades de negócio e fronteiras de domínio, favorecendo a autonomia das equipes (Megargel, Shankararaman e Walker, 2020).

A fundamentação teórica para a decomposição eficaz exige a compreensão de que cada serviço deve possuir responsabilidades únicas e bem definidas. O Design Orientado a Domínio propõe a divisão do sistema em contextos agregados, onde cada contexto agrupa conceitos coerentes e estabelece limites claros de responsabilidade (Rademacher, Sorgalla e Sachweh, 2018). Por outro lado, abordagens mais sistemáticas, baseadas na análise do fluxo de dados, buscam reduzir a influência do fator intuitivo dos desenvolvedores, oferecendo passos prescritivos baseados nas unidades de armazenamento e processamento de informações (Li, Zhang e Jia, 2019). A comparação entre essas técnicas permite identificar qual abordagem melhor atende aos requisitos de performance e complexidade de implementação em projetos de modernização de sistemas.

A metodologia aplicada neste estudo seguiu os fundamentos da pesquisa experimental, submetendo os objetos de análise a variáveis controladas para avaliar os resultados gerados (Gil, 2008). O levantamento bibliográfico concentrou-se na identificação do estado atual das técnicas de decomposição, visando oferecer evidências práticas para a comunidade acadêmica e profissional. O caso de estudo selecionado foi um sistema de gestão de chamados e faturamento, classificado na categoria de sistemas de planejamento de recursos empresariais, os quais são utilizados por 43,3% das empresas na União Europeia (Eurostat, 2024). O sistema original era responsável pela abertura de chamados para compra de equipamentos e pela emissão do faturamento correspondente, apresentando problemas típicos de monólitos, como o acoplamento de regras de precificação, descontos e multas em um único fluxo síncrono.

Para a simulação do ambiente experimental, o sistema foi desenvolvido utilizando a plataforma .NET 8, com o template ASP.NET Core Web API e seguindo o padrão REST. A persistência de dados foi estruturada em um banco de dados SQL Server com o auxílio do Entity Framework. O monólito inicial foi projetado para que todas as entidades e casos de uso coexistissem no mesmo sistema e base de dados, replicando o cenário de alto acoplamento onde a gestão de itens e os cálculos complexos de faturamento ocorriam de forma interdependente. Essa estrutura permitiu a observação de sintomas como lentidão na abertura de chamados e dificuldades na manutenção do código devido ao encapsulamento excessivo de funções distintas (Chen, Li e Li, 2017).

A aplicação da técnica de Design Orientado a Domínio foi conduzida através de cinco critérios iterativos. O primeiro critério envolveu a modelagem de subdomínios, agrupando conceitos a partir de histórias de usuário para criar um mapa de contexto inicial. O segundo critério focou na divisão por funcionalidades, alinhando os contextos aos fluxos do sistema e agrupando entidades frequentemente utilizadas em conjunto. O terceiro critério considerou a estrutura das equipes, visando garantir autonomia organizacional. O quarto critério analisou a volatilidade, isolando funcionalidades que sofrem mudanças frequentes, como as regras de faturamento e contratos. Por fim, o quinto critério abordou requisitos não funcionais, como segurança e disponibilidade, para identificar caminhos críticos que exigiam isolamento.

A segunda técnica, baseada na análise do fluxo de dados, iniciou-se com a captura do fluxo real do sistema para minimizar a subjetividade. Foram construídos diagramas de fluxo de dados em dois níveis: o nível zero, derivando processos e entidades externas, e o nível um, detalhando subprocessos e armazenamentos de dados. A construção seguiu regras rigorosas onde dados não se movem sem um processo e processos não criam informações sem um armazenamento intermediário. Após a geração de um diagrama enxuto, as relações de leitura e escrita foram convertidas em uma matriz de dependências. O agrupamento final foi realizado através de um algoritmo que unificou processos relacionados ao mesmo armazenamento de dados, garantindo que cada microsserviço candidato nascesse com uma base de dados exclusiva (Li, Zhang e Jia, 2019).

Para a comparação técnica, ambos os conjuntos de microsserviços candidatos foram implementados utilizando as mesmas tecnologias do monólito. As comunicações síncronas foram realizadas via chamadas REST, enquanto as comunicações assíncronas utilizaram mensageria com RabbitMQ. O banco de dados do monólito foi decomposto para refletir a nova arquitetura, gerando bases exclusivas por serviço. Os testes de performance foram executados com scripts da ferramenta k6, simulando cinco usuários realizando requisições simultâneas durante um período de 30 segundos, permitindo a coleta de métricas de latência, vazão e sucesso das operações.

Os resultados da aplicação do Design Orientado a Domínio revelaram uma estrutura composta por quatro microsserviços: Chamados, Contratos, Faturamento e Fornecedor. Na primeira iteração, a divisão baseou-se estritamente nas entidades de negócio. Contudo, a análise de sinergia e frequência de comunicação indicou que as funcionalidades de equipamentos e serviços possuíam alta dependência com a gestão de chamados, levando à sua unificação. A entidade fornecedor permaneceu isolada por ser referenciada tanto em chamados quanto em faturamento. A volatilidade das regras de contratos, que exigiam atualizações constantes em bônus e multas, justificou a criação de um serviço específico, separando-o do motor de faturamento principal. Essa abordagem resultou em serviços com alta coesão e responsabilidades atômicas, refletindo fielmente o domínio de negócio.

Em contraste, a técnica baseada no fluxo de dados resultou em apenas dois microsserviços candidatos: um voltado para a gestão de chamados e outro para o faturamento. A matriz de leitura e escrita identificou oito unidades de armazenamento e oito processos principais. O algoritmo de agrupamento fundiu processos que compartilhavam os mesmos dados, resultando no Grupo A, responsável pela identificação e gerenciamento de chamados, e no Grupo B, focado em precificação, contratos e geração de faturamento. Essa técnica mostrou-se significativamente mais direta e menos dependente de intuição, oferecendo um caminho prescritivo que resolveu o acoplamento principal do monólito ao separar os dois grandes blocos de dependências de dados.

A comparação entre os resultados evidenciou que diferentes técnicas de decomposição podem produzir arquiteturas divergentes, mesmo para sistemas com número reduzido de entidades. O Design Orientado a Domínio demandou maior esforço intelectual e múltiplas iterações para refinar as fronteiras dos contextos, enfrentando desafios na identificação de omissões de informação que nem sempre estão mapeadas de forma sistemática (Rademacher, Sorgalla e Sachweh, 2018). Por outro lado, a técnica de fluxo de dados ofereceu passos mais céleres, embora possa resultar em serviços com granularidade menor do que a sugerida por uma análise puramente orientada ao negócio. Observou-se que o conjunto gerado pelo Design Orientado a Domínio apresentou menor vazamento de conceitos entre as fronteiras, indicando uma coesão superior em cada contexto, conforme preconizado pela literatura (Kapferer e Zimmermann, 2020).

No que tange ao desempenho, o monólito original apresentou uma execução eficiente, processando 670 requisições com sucesso em 30 segundos, com um percentil 90 de 25,46 ms. Essa performance é atribuída ao fato de todos os domínios serem acessados em uma única transação, compartilhando o mesmo banco de dados. Os microsserviços gerados pela técnica de fluxo de dados apresentaram resultados muito próximos ao monólito, com 653 requisições bem-sucedidas. O serviço de chamados registrou um percentil 90 de 20,97 ms, enquanto o de faturamento, operando de forma assíncrona, obteve 6 ms. A adição do overhead de mensageria para publicar e consumir dados não impactou severamente a latência total, demonstrando a eficiência dessa partição.

Os microsserviços derivados do Design Orientado a Domínio, entretanto, apresentaram um desempenho inferior em comparação aos demais modelos. Foram realizadas 644 requisições com sucesso, mas o percentil 90 elevou-se para 45,86 ms no serviço de chamados e 39 ms no de faturamento. A maior granularidade dessa proposta, embora benéfica para a organização do código e isolamento de responsabilidades, gerou uma dependência maior de comunicações síncronas entre os quatro serviços. A necessidade de um serviço consultar dados em outro para completar suas operações introduziu latência adicional, confirmando que a fragmentação excessiva pode prejudicar a performance se não for acompanhada de estratégias robustas de replicação de dados ou cache (Kapferer e Zimmermann, 2020).

A discussão dos resultados aponta que a escolha da técnica de decomposição deve ser pautada pelos objetivos primordiais da migração. Se a prioridade da organização é a clareza do domínio de negócio e a independência total das equipes, o Design Orientado a Domínio oferece uma estrutura mais representativa e atômica, apesar da complexidade de implementação e do impacto na latência. Caso o foco seja a rapidez na entrega e a manutenção de níveis de performance próximos ao monólito, a técnica baseada em fluxo de dados mostra-se superior por ser mais prescritiva e gerar menos integrações remotas. A redução das comunicações síncronas é um fator determinante para o sucesso da arquitetura, e a técnica de fluxo de dados atacou diretamente esse ponto ao agrupar processos por afinidade de armazenamento.

As limitações deste estudo residem na escala da simulação, que utilizou um número controlado de usuários e entidades. Em sistemas de larga escala, a complexidade das integrações no modelo de Design Orientado a Domínio poderia crescer exponencialmente, exigindo padrões como o de agregação de dados ou visualizações materializadas para mitigar a latência. Pesquisas futuras poderiam explorar a aplicação dessas técnicas em sistemas com centenas de entidades, avaliando como a automação do processo de decomposição pode reduzir ainda mais o fator subjetivo e os erros de partição. Além disso, a inclusão de técnicas de cache e replicação de dados nos testes de performance poderia oferecer uma visão mais equilibrada sobre os custos de infraestrutura de cada abordagem.

A análise comparativa reforça que não existe uma solução única para a decomposição de monólitos. O Design Orientado a Domínio tende a oferecer resultados que melhor representam o negócio, promovendo uma segregação de responsabilidades mais profunda. No entanto, essa granularidade elevada impõe desafios técnicos significativos. A técnica baseada no fluxo de dados, por sua vez, simplifica o processo de decisão e garante resultados de performance consistentes, sendo uma porta de entrada eficaz para organizações que buscam resultados rápidos com menor risco técnico. A valorização da etapa de decomposição antes da execução da implementação é, portanto, um passo crítico para evitar retrabalhos e garantir que a nova arquitetura de microsserviços cumpra sua promessa de escalabilidade e agilidade.

Conclui-se que o objetivo foi atingido, uma vez que a comparação prática entre as técnicas de Design Orientado a Domínio e análise de fluxo de dados demonstrou que, embora a primeira ofereça maior coesão e alinhamento ao negócio, a segunda proporciona uma implementação mais simples e com melhor desempenho técnico. A escolha entre os métodos deve considerar o equilíbrio entre a granularidade desejada e a tolerância à latência de rede, evidenciando que a decomposição baseada em dados é mais eficiente para manter a performance, enquanto a orientada ao domínio é superior para a organização e evolução independente de capacidades de negócio complexas.

Referências Bibliográficas:

ABGAZ, Y.; et al. Decomposition of monolith applications into microservices architectures: a systematic review. IEEE Transactions on Software Engineering, v. 49, n. 8, p. 4213–4242, 2023. Disponível em: https://doi.org/10.1109/TSE.2023.3287297. Acesso em: 29 jul. 2025.

CHEN, R.; LI, S.; LI, Z. From monolith to microservices: a dataflow-driven approach. In: ASIA-PACIFIC SOFTWARE ENGINEERING CONFERENCE (APSEC), 24., 2017, Nanjing, China. Anais… Nanjing: IEEE, 2017. p. 466–475. Disponível em: https://doi.org/10.1109/APSEC.2017.53. Acesso em: 10 ago. 2025.

EUROSTAT. Cloud computing – statistics on the use by enterprises. 2024. Disponível em: https://ec.europa.eu/eurostat/statistics-explained/index.php?title=Cloud_computing_-_statistics_on_the_use_by_enterprises. Acesso em: 12 ago. 2025

FOWLER, M. Microservices. 2014. Disponível em: https://www.martinfowler.com/articles/microservices.html. Acesso em: 16 jul. 2024.

GIL, A. C. Métodos e técnicas de pesquisa social. 6. ed. São Paulo: Atlas, 2008.

KALSKE, M. Transforming monolithic architecture towards microservice architecture. 2017. Monografia (Bacharelado em Ciência da Computação) – University of Helsinki, Helsinki. Disponível em: https://doi.org/10.1145/3573074.3573091. Acesso em: 11 ago. 2025.

KAPFERER, S.; ZIMMERMANN, O. Domain-driven service design: context modeling, model refactoring and contract generation. In: SYMPOSIUM AND SUMMER SCHOOL ON SERVICE-ORIENTED COMPUTING, 2020, Cham. Anais… Cham: Springer, 2020. p. 189–208. Disponível em: https://doi.org/10.1007/978-3-030-64846-6_11. Acesso em: 29 jul. 2025.

LI, S.; ZHANG, H.; JIA, Z.; LI, Z.; ZHANG, C.; LI, J.; GAO, Q.; GE, J.; SHAN, Z. A dataflow-driven approach to identifying microservices from monolithic applications. Journal of Systems and Software, v. 157, p. 1–14, 2019. Disponível em: https://doi.org/10.1016/j.jss.2019.07.008. Acesso em: 11 ago. 2025.

MEGARGEL, A.; SHANKARARAMAN, V.; WALKER, D. Migrating from monoliths to cloud-based microservices: a banking industry example. In: CLOUD COMPUTING FOR BUSINESS APPLICATIONS. Cham: Springer, 2020. p. 61–78. Disponível em: https://doi.org/10.1007/978-3-030-33624-0_4. Acesso em: 14 ago. 2025.

RADEMACHER, F.; SORGALLA, J.; SACHWEH, S. Challenges of domain-driven microservice design: a model-driven perspective. IEEE Software, v. 35, n. 3, p. 36–43, 2018. Disponível em: https://doi.org/10.1109/MS.2018.2141028. Acesso em: 29 jul. 2025.

Resumo executivo oriundo de Trabalho de Conclusão de Curso da Especialização em Engenharia de Software do MBA USP/Esalq

Para saber mais sobre o curso, clique aqui e acesse a plataforma MBX Academy