Resumo Executivo

Michel André Kaminski; Alexandre Leite Rangel

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

A equoterapia consolida-se como uma prática terapêutica de relevância crescente no cenário brasileiro, utilizando o cavalo como ferramenta mediadora para promover avanços significativos na qualidade de vida de indivíduos com diversas condições de saúde. Entre as principais indicações para essa modalidade, destacam-se o Transtorno do Espectro Autista, a síndrome de Down (Castro, 2024) e a paralisia cerebral (Moraes et al., 2015). O reconhecimento dessa prática fundamenta-se nos benefícios observados no desenvolvimento psicomotor, no aprimoramento do equilíbrio e no fortalecimento de competências cognitivas e emocionais. A integração entre o movimento rítmico do animal e a assistência de equipes multidisciplinares qualificadas gera resultados terapêuticos positivos que auxiliam na reabilitação integral dos praticantes (Araújo, 2023). Com a existência de mais de 400 centros de equoterapia distribuídos pelo território nacional, a demanda por atendimentos especializados apresenta uma curva ascendente, exigindo estruturas de gestão cada vez mais eficientes (Castro, 2024). Nesse contexto, a adoção de sistemas de informação em saúde, incluindo prontuários eletrônicos e ferramentas de suporte à decisão, torna-se um fator determinante para a melhoria da eficiência operacional e a mitigação de erros, influenciando diretamente os desfechos clínicos dos pacientes (Richemond et al., 2023). Tais plataformas tecnológicas possibilitam o armazenamento centralizado, a análise criteriosa e o compartilhamento seguro de dados, o que facilita o acesso a informações críticas e fundamenta tomadas de decisão mais precisas (Guha e Kumar, 2018). Além do suporte clínico, a informatização automatiza processos administrativos complexos, como o agendamento de sessões e o faturamento, reduzindo a sobrecarga dos profissionais e otimizando o tempo dedicado ao atendimento direto (Khan et al., 2022). A precisão dos dados e a coordenação entre equipes são vitais em centros que gerenciam grandes volumes de informações, pois a ausência de ferramentas digitais adequadas resulta em limitações operacionais severas e riscos aumentados de falhas (Joseph, 2023).

A arquitetura de software que sustenta essas aplicações desempenha um papel crucial na longevidade e na capacidade de evolução do sistema. Sistemas monolíticos, caracterizados pela interligação estreita de todos os componentes em um único bloco indivisível, embora simplifiquem o desenvolvimento inicial, impõem desafios significativos em termos de escalabilidade e manutenção (Ponce et al., 2019). À medida que a complexidade do negócio aumenta e o número de usuários cresce, as limitações do monólito tornam-se evidentes, dificultando a adaptação a novas demandas tecnológicas e operacionais (Newman, 2021). Em contrapartida, a arquitetura de microsserviços propõe a fragmentação do sistema em unidades independentes e autônomas, que podem ser desenvolvidas, implantadas e escaladas de forma isolada. Essa abordagem confere maior flexibilidade, permitindo que cada componente evolua de maneira independente e responda rapidamente às necessidades de mercado, elevando a eficiência operacional (Fowler, 2014; Richardson, 2018). Organizações que realizam a transição para microsserviços frequentemente observam ganhos em agilidade e redução de custos de manutenção a longo prazo (Lenarduzzi et al., 2020). A migração de sistemas legados para essa nova estrutura melhora a resiliência da aplicação, permitindo que cada serviço opere de forma isolada, o que facilita a introdução de novos recursos sem comprometer a estabilidade do ecossistema completo (Ponce et al., 2019; Knoche e Hasselbring, 2018). O objetivo central desta análise técnica reside na exploração de estratégias de migração de um sistema de equoterapia, originalmente desenvolvido em arquitetura monolítica pela empresa Maktech Software Development LTDA para a Organização da Sociedade Civil Coletivo Inclusão, visando preparar a plataforma para suportar uma base maior de usuários e habilitar a adoção de tecnologias heterogêneas.

O processo metodológico adotado caracteriza-se como uma pesquisa aplicada, voltada à resolução de problemas práticos por meio do desenvolvimento de soluções tecnológicas (Cajueiro, 2013). A investigação iniciou-se com uma análise exaustiva do sistema legado, identificando gargalos de escalabilidade e pontos de acoplamento excessivo. O mapeamento detalhado de entidades, serviços e repositórios permitiu a organização dos dados em contextos funcionais bem definidos, abrangendo a gestão de usuários, cavalos, praticantes e evoluções clínicas. Para fundamentar a decomposição do sistema, utilizou-se a Linguagem de Modelagem Unificada com o suporte da ferramenta PlantUML, o que possibilitou a representação gráfica da estrutura e do comportamento das entidades. A modelagem resultante foi confrontada com as necessidades de expansão da OSC Coletivo Inclusão, revelando que a estrutura de dados original concentrava toda a lógica de negócio em um único repositório, característica intrínseca de arquiteturas monolíticas. A estratégia de migração baseou-se no padrão Strangler Fig, que preconiza a substituição gradual de funcionalidades do monólito por novos microsserviços, garantindo que o sistema original permaneça operacional durante todo o período de transição (Fowler, 2014; Richardson, 2018). O planejamento incluiu a definição de contextos limitados por meio do Domain-Driven Design, buscando traduzir as regras de negócio da equoterapia diretamente para a estrutura do software.

A execução técnica da migração envolveu a criação de esquemas de banco de dados exclusivos para cada microsserviço, assegurando a modularidade e a independência dos dados. O código-fonte foi reorganizado em múltiplos repositórios Git, substituindo o modelo de repositório único. O microsserviço de usuários foi o primeiro a ser desenvolvido, dada sua menor complexidade relativa e sua essencialidade para as demais funções. Implementado com o framework Spring Boot, este serviço assumiu a responsabilidade pela gestão de acessos e perfis. Para a migração dos dados, utilizou-se a ferramenta Liquibase, que permitiu a criação de esquemas e a transferência controlada de registros do banco antigo para os novos esquemas específicos. O comando generateChangeLog foi fundamental para gerar as unidades atômicas de mudança, garantindo rastreabilidade e consistência. O processo de importação de dados da tabela de acessos para o novo microsserviço foi desenhado para preservar as informações históricas, assegurando a continuidade do uso do sistema sem perda de integridade. No repositório original, as classes de repositórios e entidades relacionadas a usuários foram removidas e substituídas por chamadas ao novo serviço via Gateway.

A comunicação entre as camadas do sistema foi otimizada com o uso de Objetos de Transferência de Dados, os DTOs, visando desacoplar o frontend do backend e reduzir a carga de dados trafegados. A conversão entre DTOs e entidades foi automatizada com a biblioteca MapStruct, que gera código eficiente para o mapeamento de atributos. No âmbito da segurança, o microsserviço de usuários projetou-se com foco na proteção de dados sensíveis. A autenticação e a autorização foram centralizadas em um Gateway, que utiliza o padrão Spring Cloud Gateway MVC para roteamento dinâmico. A validação de identidade ocorre por meio de tokens JSON Web Token, assinados com chaves RSA de criptografia assimétrica. As senhas dos usuários são protegidas por algoritmos de hashing BCrypt com adição de salt, garantindo que as credenciais não sejam armazenadas em texto claro. O Gateway atua como um ponto único de entrada, validando os tokens e encaminhando as permissões já processadas para os microsserviços internos, que utilizam filtros do Spring Security para aplicar restrições baseadas em perfis de acesso.

O detalhamento operacional da migração estendeu-se aos módulos de gestão de cavalos e praticantes. O serviço dedicado aos animais passou a gerenciar informações complexas, incluindo vacinação, alimentação, pelagens, raças e procedimentos odontológicos ou de ferrageamento. Anteriormente, esses dados estavam dispersos e fortemente acoplados a outras tabelas no monólito. Com a nova arquitetura, cada entidade relacionada ao cavalo, como o registro de peso e vermifugação, foi isolada em um contexto próprio. Da mesma forma, o módulo de praticantes foi reestruturado para suportar a densidade de informações exigida pela equoterapia, englobando avaliações fisioterapêuticas, pedagógicas e psicológicas. A complexidade desse módulo é evidenciada pela necessidade de registrar dados sobre desenvolvimento motor, comunicação, comportamento social e histórico escolar. A separação funcional permitiu que o serviço de evoluções clínicas, que registra o progresso diário dos praticantes em cada sessão, pudesse consultar os dados de cavalos e praticantes exclusivamente via APIs REST, eliminando a dependência de chaves estrangeiras em nível de banco de dados.

Para garantir a paridade entre os ambientes de desenvolvimento e produção, utilizou-se a plataforma Docker. Tanto o sistema monolítico remanescente quanto os novos microsserviços foram empacotados em contêineres leves e portáteis. A orquestração desses serviços foi realizada com Docker Compose, permitindo que o banco de dados, o Gateway e os múltiplos serviços fossem iniciados simultaneamente de forma controlada. O uso de dois bancos de dados distintos — um para o monólito e outro compartilhado entre os microsserviços, mas com esquemas isolados — reforçou a separação lógica das arquiteturas. O processo de build foi automatizado com o Maven, gerando artefatos padronizados que facilitam a implantação contínua. A interface do usuário, desenvolvida com o framework Vaadin, foi adaptada para realizar chamadas ao Gateway, que por sua vez reescreve as rotas para os endpoints específicos de cada microsserviço, tornando a transição transparente para o usuário final.

Os resultados obtidos com a migração demonstraram uma evolução clara na robustez do sistema de equoterapia. Em testes de disponibilidade, a parada forçada do contêiner do monólito resultou na indisponibilidade total da plataforma, evidenciando o ponto único de falha. Em contraste, na arquitetura de microsserviços, a interrupção deliberada do serviço de praticantes não afetou o funcionamento dos demais módulos, como o de cavalos ou de usuários. O Gateway continuou operando e roteando requisições normalmente, mantendo a disponibilidade parcial da aplicação. Esse isolamento de falhas é uma característica fundamental para sistemas que pretendem escalar e manter alta confiabilidade. No que tange ao desempenho, observou-se que a arquitetura distribuída consome mais memória total devido à execução de múltiplos contêineres, porém o uso de CPU permaneceu estável e baixo em ambos os modelos. Em um cenário de produção real, essa estrutura permite o balanceamento de carga direcionado, onde serviços com maior demanda, como o de evoluções, podem receber mais recursos computacionais de forma independente.

A análise dos tempos de execução revelou dados quantitativos importantes. A compilação do frontend apresentou uma leve redução, passando de 28 s no monólito para 27 s na nova estrutura. A inicialização do ambiente via Docker Compose, embora mais lenta no build inicial (34 s contra 13,5 s do monólito), mostrou-se eficiente na manutenção da independência dos serviços. Um ponto de destaque foi a geração de relatórios complexos, abrangendo 3411 evoluções. No monólito, o tempo médio foi de 15,46 s, enquanto nos microsserviços o tempo subiu para 18,40 s. Esse aumento de aproximadamente 19% justifica-se pela latência de rede introduzida pelas múltiplas chamadas entre serviços e pela necessidade de agregar dados que não estão mais no mesmo banco. Contudo, essa diferença é compensada pela agilidade no ciclo de desenvolvimento. No modelo monolítico, qualquer alteração mínima exigia a recompilação total e a parada completa do sistema para atualização. Com microsserviços, atualizações em módulos específicos, como o de usuários, ocorrem em apenas 3,8 s de compilação, sem interromper as funcionalidades de gestão de cavalos ou praticantes.

A discussão dos resultados aponta que a modularidade alcançada facilita a manutenção evolutiva. A separação da interface de usuário como um módulo independente permite a aplicação de padrões como o UI Composition, onde a interface é montada a partir de componentes que se comunicam com diferentes backends (Newman, 2019). A centralização da segurança no Gateway, com a rotação de tokens JWT e chaves RSA, fortaleceu a integridade do sistema contra acessos não autorizados. Entretanto, a migração revelou desafios inerentes a sistemas distribuídos. O trabalho repetitivo na criação de DTOs e a maior complexidade no processo de depuração exigem equipes preparadas para lidar com a rastreabilidade de requisições que atravessam múltiplos serviços. A ausência de transações distribuídas nativas sugere que, para evoluções futuras, a implementação do padrão Saga seja necessária para garantir a consistência eventual em processos que envolvem múltiplos serviços simultaneamente (Newman, 2019).

A experiência com o módulo de evoluções mostrou-se particularmente complexa, pois este depende diretamente de dados de cavalos e praticantes. A solução de manter apenas referências mínimas e validar dados via chamadas de API evitou o acoplamento, mas aumentou o número de requisições. Para mitigar esse efeito e melhorar o desempenho da geração de relatórios, a adoção de um banco de dados auxiliar em modo somente leitura, alimentado por replicação ou mensageria, surge como uma alternativa viável para reduzir a latência. Além disso, a integração de sistemas de armazenamento de objetos, como o MinIO, poderia otimizar a gestão de documentos e imagens dos praticantes, oferecendo maior escalabilidade para o armazenamento de arquivos em nuvem. Mecanismos de resiliência, como timeouts e circuit breakers, também são recomendados para evitar que a lentidão em um serviço cause um efeito cascata em todo o ecossistema.

Conclui-se que o objetivo foi atingido, uma vez que a migração do sistema de equoterapia para uma arquitetura de microsserviços foi realizada com sucesso em caráter de prova de conceito, demonstrando viabilidade técnica e ganhos significativos em modularidade, isolamento de falhas e flexibilidade tecnológica. A aplicação do padrão Strangler Fig permitiu uma transição segura, mantendo a integridade dos dados históricos e a continuidade operacional. Embora a arquitetura distribuída introduza maior complexidade de gerenciamento e uma leve latência em operações de agregação de dados, os benefícios em termos de escalabilidade seletiva e agilidade no ciclo de manutenção superam esses desafios para cenários de expansão futura. O trabalho estabeleceu uma base sólida para a evolução do sistema, preparando-o para atender múltiplos centros de equoterapia com requisitos heterogêneos e garantindo uma infraestrutura capaz de suportar novas integrações tecnológicas de forma sustentável.

Referências Bibliográficas:

Araújo, F.R.D. 2023. Equoterapia: uma abordagem multidimensional para o desenvolvimento biopsicossocial de indivíduos com deficiências e necessidades específicas. Revista Ibero-Americana de Humanidades, Ciências e Educação 9(10): 809-824.

Cajueiro, R.L.P. 2013. Manual para Elaboração de Trabalhos Acadêmicos: Guia prático do estudante. 1ed. Saraiva, Rio de Janeiro, RJ, Brasil.

Castro, F.C. 2024. Equoterapia Como Prática Educativa Para Estudantes Com Transtorno Do Espectro Autista. Zenodo 1(1): 1-7.

Fowler, M. 2014. Microservices: a definition of this new architectural term. Disponível em: https://martinfowler.com/articles/microservices.html. Acesso em: 23 set. 2024.

Guha, S.; Kumar, S. 2018. Emergence of Big Data Research in Operations Management, Information Systems, and Healthcare: past contributions and future roadmap. Production and Operations Management 27(9): 1724-1735.

Joseph, A. 2023. Information Systems in Healthcare: Improving Patient Care and Efficiency. Business Studies Journal 15(3): 1-3.

Khan, M.A.; Din, I.U.; Majali, T.; Kim, B.-S. 2022. A Survey of Authentication in Internet of Things-Enabled Healthcare Systems. Sensors 22(23): 9089.

Knoche, H.; Hasselbring, W. 2018. Using Microservices for Legacy Software Modernization. IEEE Software 35(3): 44-49.

Lenarduzzi, V.; Lomio, F.; Saarimäki, N.; Taibi, D. 2020. Does Migrating a Monolithic System to Microservices Decrease the Technical Debt? Journal of Systems and Software 169(110710): 1-36.

Moraes, A.G.; Silva, M.; Copetti, F.; Abreu, A.C.; David, A.C. 2015. Equoterapia no Controle Postural e Equilíbrio em Indivíduos com Paralisia Cerebral. Revista Neurociências 23(4): 546-554.

Newman, S. 2019. Monolith to Microservices: Evolutionary Patterns to Transform Your Monolith. 1ed. O’Reilly Media, California, EUA.

Newman, Sam. 2021. Building Microservices: Designing Fine-Grained Systems. 2. ed. California: O’Reilly Media. 612 p.

Ponce, F.; Marquez, G.; Astudillo, H. 2019. Migrating from Monolithic Architecture to Microservices: A Rapid Review. 2019 38th International Conference of the Chilean Computer Science Society (SCCC) 38: 1-7.

Richardson, C. 2018. Microservices Patterns: With Examples in Java. 1ed. Manning, Shelter Island, NY, EUA.

Richemond, D.; Huggins-Jordan, T.D. 2023. The Impact of Health Information Systems on Patient Outcomes. OALib 10(08): 1-11.

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