Este projeto tem como objetivo realizar a migração de um sistema monolítico tradicional para uma arquitetura de Monólito Modular (MOM). A refatoração busca melhorar a escalabilidade, modularidade e manutenibilidade do sistema através da aplicação de princípios como Domain-Driven Design (DDD), Command Query Responsibility Segregation (CQRS) e Arquitetura Limpa (AL).
Migrar um sistema monolítico legado para uma arquitetura de monólito modular (Modular Monolith) requer identificar módulos internos bem definidos.
Um monólito modular é uma forma de organizar a aplicação em módulos coesos e fracamente acoplados, porém mantendo implantação unificada.
Essa abordagem busca combinar os benefícios de modularidade (como separação de responsabilidades e possibilidade de evolução independente) com a simplicidade do monólito (evitando, por ora, a complexidade de microsserviços distribuídos).
Estudos ressaltam que, para uma boa modularização, é preciso alta coesão interna e baixo acoplamento externo entre módulos. Em outras palavras, módulos devem agrupar funcionalidades contextualmente relacionadas e expor interfaces claras, de modo que cada módulo encapsule código relacionado a um conceito ou funcionalidade específica. Isso melhora a manutenibilidade e clareza arquitetural, pois desenvolvedores podem evoluir cada módulo com impacto mínimo nos demais. Além disso, módulos bem definidos facilitam futura extração para microsserviços caso necessário, provendo um caminho evolutivo com menor esforço .
Identificar esses módulos em um monólito não é trivial. A literatura propõe diversos métodos – desde análises de domínio até mineração de repositório – cada um revelando diferentes vistas do sistema. Este relatório propõe uma sequência encadeada de métodos para identificação de módulos em sistemas monolíticos visando migração para um monólito modular. A recomendação baseia-se em evidências de pesquisas acadêmicas, estudos de caso, experiências open-source e artigos técnicos. Em cada etapa da sequência, detalhamos: (1) os inputs necessários, (2) o tipo de análise realizada, (3) os outputs gerados, e (4) como cada output alimenta a etapa seguinte. Em seguida, discutimos como cada método contribui para critérios de qualidade modular (coesão, acoplamento, testabilidade, manutenibilidade, escalabilidade). Por fim, apresentamos as principais métricas para avaliar a qualidade dos módulos, destacando as mais robustas e utilizadas na prática e na academia.
| Etapa | Método de Análise | Foco da Análise | Principais Ferramentas/Referências | Resultado Esperado |
|---|---|---|---|---|
| 1. | Domínio & Responsabilidades | Análise de domínio do negócio e responsabilidades do sistema (DDD, SRP) | Entrevistas, documentação; Service Cutter , modelagem de bounded contexts (Martin Fowler) | Lista inicial de módulos propostos alinhados a contextos de negócio ou funcionalidades principais (módulos coesos conceitualmente) |
| 2. | Dependências Estáticas | Análise estática de dependências no código (estrutura) | Ferramentas de análise estática: Arcan, Sonargraph , dependência em grafo, clusterização (ex.: algoritmo Bunch) | Clusters de classes/pacotes altamente conectados; detecção de ciclos e dependências fortes; sugestão de fronteiras modulares no código |
| 3. | Dependências Dinâmicas | Análise dinâmica de execução (runtime) | Logs de execução, tracing (ex.: APM, instrumentos customizados); ferramentas como Monolysis (MonoBreak) , perfis de chamadas | Agrupamentos de classes/métodos que colaboram em cenários de uso reais; mapa de chamadas entre módulos candidatos durante operações típicas |
| 4. | Histórico de Versões | Análise do repositório e evolução (mineração de histórico) | Git logs, análise de commits (scripts, CodeScene); pesquisas MSR (ex.: Mazlami et al. ) | Conjuntos de classes/arquivos com forte acoplamento lógico (alta frequência de mudanças conjuntas); indicação de módulos de manutenção (componentes que coevoluem) |
| 5. | Consolidação e Refinamento | Integração dos resultados das etapas anteriores | Workshops de arquitetura, visualização de sobreposições (ex.: matrizes de dependência DSM), critérios de qualidade | Definição final dos módulos do monólito modular, com fronteiras ajustadas para máxima coesão e mínimo acoplamento; mapa de módulos e suas interfaces de integração |