Resumo Executivo

Rafael Ramos Costa; Eduardo Fernando Mendes

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

A evolução acelerada da tecnologia e a crescente necessidade de inovação impõem desafios significativos às organizações que mantêm sistemas legados. Esses sistemas, muitas vezes desenvolvidos sem planejamento estruturado e com baixo nível de documentação, tornam-se obstáculos à escalabilidade, à manutenção e à adequação às novas demandas do negócio. O impacto dessa realidade é refletido em perdas econômicas expressivas, uma vez que o custo da baixa qualidade de software nos Estados Unidos ultrapassou 2 trilhões de dólares, dos quais uma parcela considerável está associada à manutenção de sistemas antigos, falhas operacionais e dívidas técnicas acumuladas (Krasner, 2020). Em 2022, o cenário agravou-se, com destaque para os crescentes custos associados à insegurança cibernética e à dificuldade de adaptação de arquiteturas rígidas (Krasner, 2022). Diante desse contexto, torna-se evidente a necessidade de estratégias que viabilizem a modernização desses sistemas de forma estruturada e segura, garantindo que a dívida técnica não inviabilize a continuidade das operações comerciais.

Entre as abordagens possíveis para enfrentar a obsolescência tecnológica, destaca-se o Domain-Driven Design (DDD), proposto como uma alternativa capaz de alinhar a estrutura do software ao domínio de negócio (Evans, 2003). O DDD propõe a segmentação do sistema em bounded contexts, o uso de uma linguagem ubíqua e a aplicação de técnicas como o event storming, que visam aumentar a clareza da modelagem e a comunicação entre stakeholders técnicos e não técnicos (Vernon, 2013). Práticas de refatoração orientadas por domínio contribuem significativamente para a manutenibilidade do código e a qualidade da arquitetura, permitindo que o software evolua em sincronia com as mudanças nas regras de negócio (Fowler, 2018). No entanto, a aplicação do DDD em sistemas legados apresenta desafios relevantes, como a resistência à mudança organizacional, a ausência de documentação fidedigna, a curva de aprendizado acentuada da equipe e a complexidade de realizar mudanças profundas mantendo a operação ativa (Rademacher et al., 2018). Tais dificuldades reforçam a importância de análises empíricas que verifiquem a viabilidade e os impactos reais dessa adoção em ambientes corporativos de alta criticidade.

A fundamentação teórica que sustenta a modernização de sistemas complexos exige a compreensão de que o software não é apenas um conjunto de instruções técnicas, mas uma tradução de processos organizacionais. Quando essa tradução falha ou se torna obsoleta, a empresa perde agilidade competitiva. A adoção de padrões arquiteturais modernos busca reverter esse quadro por meio da modularização e do isolamento de responsabilidades. Estudos recentes reforçam os benefícios do DDD em contextos industriais, documentando ganhos significativos de clareza arquitetural e qualidade estrutural a partir da aplicação da abordagem em sistemas legados (Özkan et al., 2023). A definição de bounded contexts surge como o pilar fundamental para a modularidade e a redução de conflitos semânticos, permitindo que diferentes partes do sistema possuam modelos de dados independentes e específicos para suas funções. Embora o DDD demande um esforço organizacional e técnico considerável, os benefícios tendem a superar os custos em médio e longo prazo, especialmente em setores onde as regras de negócio são complexas e mutáveis. O objetivo desta análise é investigar os impactos da adoção do Domain-Driven Design na refatoração de sistemas legados complexos, focando na estrutura do sistema, na produtividade da equipe e na qualidade do código resultante.

Para a execução da modernização, adotou-se de forma recorrente o Strangler Fig Pattern, uma estratégia de substituição gradual que permite a coexistência do sistema antigo com os novos módulos (Fowler, 2004). Essa abordagem consiste em encapsular o sistema existente e implementar novas funcionalidades progressivamente, até que o legado possa ser desativado sem causar interrupções críticas. Em ambientes complexos, essa estratégia garante entregas incrementais e reduz os riscos associados a grandes transições arquiteturais, conhecidas como substituições big bang (Tsanas, 2024). A metodologia aplicada neste estudo de caso único possui caráter misto, combinando coleta de dados qualitativos e quantitativos em uma empresa brasileira de médio porte do setor de antecipação de recebíveis. A organização em questão já havia iniciado o processo de refatoração de parte de seus sistemas, o que permitiu o acompanhamento observacional das etapas de transição e a coleta de evidências diretas sobre o processo operacional.

O delineamento da pesquisa foi estruturado para capturar a complexidade das interações entre as equipes e as ferramentas utilizadas. A coleta de dados qualitativos envolveu a realização de entrevistas exploratórias semiestruturadas com seis profissionais diretamente inseridos no projeto de refatoração. A amostra incluiu desenvolvedores, tech leads, o líder de engenharia e o líder do time de produtos, com tempos de casa variando de menos de um ano a mais de três anos. Essa diversidade de perfis garantiu uma visão multifacetada sobre os desafios técnicos e organizacionais. As entrevistas foram conduzidas via formulário eletrônico estruturado, abordando o estado do sistema pré-refatoração, os principais obstáculos enfrentados, as práticas de DDD efetivamente aplicadas e a percepção de impactos na comunicação e na produtividade. O roteiro de perguntas buscou identificar não apenas os sucessos, mas também as resistências culturais e as dificuldades de aprendizado relacionadas a conceitos como linguagem ubíqua e modelagem de entidades.

Simultaneamente, a coleta de dados quantitativos baseou-se em métricas extraídas diretamente do sistema de gestão de projetos Jira. Foram analisados dados históricos de produtividade e qualidade, considerando dois indicadores principais: o número de bugs reportados e o cycle time. Para fins de padronização, considerou-se como bug todo item categorizado com o IssueType correspondente, enquanto o cycle time foi definido como o intervalo de tempo decorrido entre a mudança do status de uma funcionalidade de “To Do” para “Finished”. A análise comparou o mês imediatamente anterior ao início da refatoração, em outubro de 2024, com o quinto mês de execução do projeto, em maio de 2025. Essa janela temporal permitiu observar o comportamento das métricas após a estabilização inicial das novas práticas arquiteturais. Além das métricas e entrevistas, foram examinados documentos técnicos produzidos durante o processo, como relatórios de sessões de event storming, modelos de bounded contexts e diagramas de arquitetura que ilustram os estados “antes” e “depois” da intervenção.

O detalhamento do processo operacional revelou que a modelagem dos contextos foi fortemente influenciada por workshops colaborativos. O event storming foi utilizado como ferramenta fundamental para alinhar os times em torno da modelagem e da priorização da refatoração, permitindo a identificação de comandos como “Analisar crédito”, “Classificar cliente” e “Liquidar parcela”, além de eventos críticos como “Nota aprovada” e “Cobrança registrada”. A visualização colaborativa promovida por esses painéis ajudou a explicitar regras de negócio que anteriormente estavam implícitas ou diluídas no código legado. Esse processo de descoberta foi essencial para definir as fronteiras dos bounded contexts, garantindo que cada serviço tivesse responsabilidades claras e contratos de comunicação bem definidos. A análise documental desses artefatos serviu como evidência concreta do amadurecimento conceitual da equipe e da evolução da arquitetura de um modelo monolítico para um modelo modular e orientado ao domínio.

Os resultados quantitativos evidenciaram que a refatoração baseada no DDD teve um impacto direto e positivo na qualidade do sistema. O levantamento realizado no Jira apontou que o número de bugs reportados caiu de 17 ocorrências no mês anterior à refatoração para apenas quatro no quinto mês do processo. Essa redução de aproximadamente 76,5% na incidência de falhas demonstra a eficácia da reescrita de partes críticas do código e da aplicação de testes mais rigorosos integrados à nova arquitetura. A queda drástica no volume de erros pode ser atribuída à redução do acoplamento entre os módulos, o que minimiza os efeitos colaterais indesejados quando alterações são realizadas em diferentes partes do sistema. Além disso, o mapeamento prévio de cenários de negócio via event storming permitiu que a equipe antecipasse problemas de integração que, no modelo anterior, só seriam detectados em ambiente de produção.

Em contrapartida à melhoria na qualidade, observou-se um aumento no tempo médio de entrega de funcionalidades. O cycle time subiu de 7,5 dias no período pré-refatoração para 9 dias durante o processo de modernização, representando um acréscimo de cerca de 20% no tempo de desenvolvimento. Esse resultado está intrinsecamente ligado à curva de aprendizado enfrentada pela equipe, que precisou assimilar novos conceitos e rituais de trabalho. A necessidade de discussões mais profundas sobre a modelagem do domínio e a definição da linguagem ubíqua consome mais tempo nas fases iniciais de desenvolvimento, mas estabelece uma base mais sólida para a evolução futura. Embora o aumento no tempo de entrega possa ser visto como um ponto negativo imediato, ele é comparável a benchmarks de mercado que indicam atrasos temporários em fases de transição arquitetural profunda. A produtividade inicial foi, portanto, sacrificada em prol da consolidação de práticas estruturais que garantem a sustentabilidade do sistema a longo prazo.

Na dimensão qualitativa, os relatos dos profissionais confirmaram que o DDD foi adotado como uma resposta necessária às dificuldades de evoluir o sistema legado de forma segura. Antes da intervenção, o sistema apresentava acoplamento excessivo, compartilhamento inadequado de bases de dados e chamadas síncronas entre componentes de domínios distintos, o que gerava um cenário de alta fragilidade. Com a delimitação dos bounded contexts, os fluxos de negócio tornaram-se mais claros e compreensíveis. Os entrevistados destacaram a melhoria na comunicação entre as áreas técnicas e de negócio como um dos principais benefícios percebidos. A introdução da linguagem ubíqua favoreceu um novo padrão de interação, tornando os processos de tomada de decisão mais participativos e fundamentados no domínio real da empresa. Esse movimento contribuiu para reduzir ruídos de comunicação e alinhar as expectativas entre os stakeholders, fortalecendo a confiança mútua no processo de desenvolvimento.

A análise dos diagramas de arquitetura revelou a transformação de um monólito complexo em uma estrutura segmentada. Os contextos de “Notas”, “Clientes”, “Análise de Crédito”, “Cobrança”, “Antecipação” e “Score” foram definidos como núcleos independentes, com interfaces de comunicação controladas. Essa modularização fortaleceu a coesão interna de cada serviço e reduziu a dependência mútua, facilitando a manutenção isolada de componentes sem o risco de impactar todo o ecossistema. A transição para essa arquitetura modular, apoiada pelo Strangler Fig Pattern, demonstrou um equilíbrio entre a continuidade operacional e a evolução técnica. Diferente de abordagens mais radicais que poderiam interromper o serviço, a migração incremental permitiu que a empresa continuasse operando enquanto os novos módulos eram validados e colocados em produção.

Apesar dos avanços, a investigação identificou obstáculos significativos que não podem ser ignorados. A ausência de documentação no sistema legado foi citada como um dificultador constante, exigindo um esforço extra de engenharia reversa para compreender as regras de negócio vigentes. Além disso, a resistência inicial de parte da equipe aos novos rituais de modelagem e à necessidade de aprendizado contínuo evidenciou que a modernização de software é, acima de tudo, um desafio cultural. A adaptação a uma cultura de colaboração transversal exige tempo e engajamento da liderança para que as práticas de DDD não sejam abandonadas diante da pressão por entregas rápidas. O impacto organizacional observado é consistente com a literatura que posiciona o DDD como um catalisador de integração entre equipes, mas ressalta que sua consolidação demanda investimento contínuo em capacitação (Özkan et al., 2023).

A discussão dos resultados sugere que a eficácia da refatoração sustentável depende da combinação de rigor técnico e alinhamento estratégico. A redução de 76,5% nos bugs é um indicador de sucesso técnico, enquanto o aumento de 20% no cycle time é um indicador do custo de transição. Para sustentar os ganhos alcançados, recomenda-se que a organização estabeleça um roadmap de continuidade que inclua o monitoramento sistemático de métricas e a realização periódica de workshops de revisão da linguagem ubíqua. A priorização estratégica de novos domínios a serem refatorados deve considerar tanto o valor de negócio quanto o nível de dívida técnica acumulada. O fortalecimento de mecanismos de governança arquitetural é essencial para assegurar que os novos módulos não degradem para um estado de alto acoplamento ao longo do tempo, preservando a modularidade conquistada.

As limitações deste estudo incluem o fato de se tratar de um caso único em um setor específico, o que restringe a generalização dos achados para outras indústrias ou empresas de diferentes portes. O período de acompanhamento de cinco meses, embora suficiente para detectar mudanças nas métricas de bugs e produtividade, pode não capturar os efeitos de longuíssimo prazo da adoção do DDD. Além disso, as métricas analisadas focaram em qualidade técnica e tempo de entrega, sem aprofundar em indicadores financeiros como o retorno sobre investimento (ROI) ou a satisfação final do cliente externo. Futuras investigações poderiam expandir o horizonte temporal de observação e incluir uma diversidade maior de organizações para validar se os padrões de redução de bugs e aumento inicial de cycle time se repetem em diferentes contextos tecnológicos.

Conclui-se que o objetivo foi atingido, demonstrando que a aplicação do Domain-Driven Design aliada ao Strangler Fig Pattern é uma estratégia eficaz para a refatoração sustentável de sistemas legados complexos. A pesquisa comprovou que a abordagem resulta em uma melhoria drástica na qualidade do software, evidenciada pela redução de 76,5% no número de bugs, e promove um alinhamento superior entre as regras de negócio e a estrutura técnica através da delimitação de bounded contexts. Embora a transição exija um investimento inicial em tempo e aprendizado, refletido no aumento de 20% no cycle time, os benefícios em termos de modularidade, manutenibilidade e clareza de comunicação justificam o esforço organizacional. A modernização gradual permitiu a continuidade das operações no setor de antecipação de recebíveis, criando uma base arquitetural sólida e adaptável para futuras evoluções tecnológicas, consolidando o DDD como uma ferramenta vital para a gestão da dívida técnica e a sustentabilidade de sistemas críticos.

Referências Bibliográficas:

Evans, E. 2003. Domain-driven design: tackling complexity in the heart of software. Addison-Wesley Professional, Boston, MA, USA.

Fowler, M. 2004. Strangler Fig Application. Disponível em: https://martinfowler.com/bliki/StranglerFigApplication.html. Acesso em: 23 ago. 2025.

Fowler, M. 2018. Refactoring: improving the design of existing code. Addison-Wesley Professional, Boston, MA, USA.

Krasner, H. 2020. The cost of poor software quality in the US: A 2020 report. Proc. Consortium Inf. Softw. QualityTM (CISQTM). Disponível em: https://www.it-cisq.org/cisq-files/pdf/CPSQ-2020-report.pdf. Acesso em: 25 mar. 2025.

Krasner, H. 2022. The cost of poor software quality in the US: A 2020 report. Proc. Consortium Inf. Softw. QualityTM (CISQTM). Disponível em: https://www.it-cisq.org/wp-content/uploads/sites/6/2022/11/CPSQ-Report-Nov-22-2.pdf. Acesso em: 25 mar. 2025.

Rademacher, F.; Sorgalla, J.; Sachweh, S. 2018. Challenges of domain-driven microservice design: A model-driven perspective. IEEE software, 35(3), 36-43. Disponível em: https://ieeexplore.ieee.org/abstract/document/8354426. Acesso em: 22 mar. 2025.

Tsanas, J. P. S. 2024. Using the Strangler Fig Pattern on a monolithic game server. Disponível em: https://static1.squarespace.com/static/6082f965d1814c6616e0988b/t/6669713c933cc067ca3dbd77/1718186301057/strangler_paper.pdf. Acesso em: 23 ago. 2025.

Vernon, V. 2013. Implementing domain-driven design. Addison-Wesley Professional, Boston, MA, USA.

Özkan, O.; Babur, Ö.; Van Den Brand, M. 2023. Refactoring with domain-driven design in an industrial context: An action research report. Empirical Software Engineering, 28(4), 94. Disponível em: https://link.springer.com/article/10.1007/s10664-023-10310-1. Acesso em: 19 mar. 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