Decisão de Arquitetura MVP Health&Med

Data: 2024-07-26
Status: Aceita

Contexto

A Health&Med, uma startup inovadora no setor de saúde, está desenvolvendo um novo sistema que irá revolucionar a Telemedicina no país. Atualmente, a startup oferece a possibilidade de agendamento de consultas e realização de consultas online (Telemedicina) por meio de sistemas terceiros como Google Agenda e Google Meetings. Recentemente, a empresa recebeu um aporte e decidiu investir no desenvolvimento de um sistema proprietário, visando proporcionar um serviço de maior qualidade, segurança dos dados dos pacientes e redução de custos. O objetivo é criar um sistema robusto, escalável e seguro que permita o gerenciamento eficiente desses agendamentos e consultas. Além de conter as funcionalidades de agendamento e realização de consultas online, o sistema terá o diferencial de uma nova funcionalidade: o Prontuário Eletrônico. O Prontuário Eletrônico permitirá o armazenamento e compartilhamento de documentos, exames, cartão de vacinas, e outros registros médicos entre as partes envolvidas, garantindo maior assertividade nos diagnósticos.

Decisão

Escolher a arquitetura para o novo sistema proprietário da Health&Med.

Opções Consideradas

1. Monolito Modular
2. Microserviços

"Você não deve iniciar um novo projeto com microsserviços, mesmo se tiver certeza de que seu aplicativo será grande o suficiente para valer a pena." — Martin Fowler

Monolito Modular foi escolhido por uma combinação de fatores que se alinham com as necessidades e objetivos do projeto:

1. Complexidade de Implementação: A arquitetura de microserviços pode ser excessivamente complexa para uma startup em fase inicial. Implementar e gerenciar dezenas ou centenas de serviços independentes requer uma infraestrutura sofisticada e uma equipe com experiência em DevOps, que pode ser um recurso limitado na Health&Med.
2. Facilidade de Desenvolvimento: Com um monolito modular, os desenvolvedores podem trabalhar em uma única base de código, o que simplifica o processo de desenvolvimento, teste e depuração. Isso é benéfico para equipes menores e permite um desenvolvimento mais rápido e eficiente.
3. Desempenho e Latência: Um monolito evita a sobrecarga de comunicação entre serviços, que pode introduzir latência significativa. Para um sistema crítico como o de agendamento e realização de consultas, a performance é crucial para garantir uma boa experiência ao usuário.
4. Custo: Gerenciar uma arquitetura de microserviços geralmente envolve custos operacionais mais altos, devido à necessidade de ferramentas de orquestração, monitoração, logging e mais. Um monolito modular pode ser mais econômico em termos de infraestrutura e ferramentas necessárias.
5. Evolução Gradual: Começar com um monolito modular permite à Health&Med lançar rapidamente um produto funcional e, à medida que o sistema e a base de usuários crescem, a empresa pode identificar melhor os pontos críticos que poderiam ser migrados para microserviços no futuro.

Consequências

• Menor complexidade inicial e curva de aprendizado reduzida.
• Desenvolvimento e entrega mais rápidos devido a um ciclo de vida de desenvolvimento simplificado.
• Custos operacionais e de infraestrutura reduzidos no início.
• Potencial dificuldade de escalar componentes individuais do sistema à medida que a base de usuários cresce.
• Menor flexibilidade para implementar e escalar novas funcionalidades de forma independente.
• Possível aumento da complexidade no futuro se a migração para microserviços for necessária.

Ações a Serem Tomadas

• Estruturar o monolito de maneira modular para garantir que as diferentes funcionalidades sejam bem isoladas e possam ser escaladas ou separadas em serviços independentes no futuro, se necessário.
• Implementar práticas de DevOps e CI/CD para facilitar o desenvolvimento, teste e implantação contínua do monolito.
• Monitorar a performance e a escalabilidade do sistema continuamente para identificar quando e se a migração para microserviços pode ser necessária.
• Garantir que a base de código seja bem documentada e que as interfaces entre os módulos sejam claramente definidas.

Leia mais sobre Monolitos Modulares em https://martinfowler.com/bliki/MonolithFirst.html