Modular o projeto Spring

Fala Givanildo, tudo bem ?

Não sei se entendi muito bem o que você gostaria de fazer. Você se refere módulos como aplicações separadas, ou partes dentro ainda de uma única aplicação.

Imagino que seja ainda divisão interna da sua aplicação web. Em geral se divide a aplicação em camadas, separando bem as responsabilidades de cada uma delas. Você poderia seguir alguma forma de implementação do padrão arquitetural MVC, muito usado nas aplicações, dividindo assim as responsabilidades de Visualização, Controle (de fluxo, das suas lógicas) e Modelo (onde se implementa de fato as regras do seu negócio).

Bom dia Rafael, não é a divisão em camadas MVC, o que preciso na verdade seria o seguinte, tenho separar os modulos de um sistema, em vários wars, jars, por exemplo: Digamos que tenha modulos Financeiro(war), Vendas(war), Cadasatro(war), e tenha um modulo Login (war) comum para que se possa acessar os modulos conforme regra de acesso/perfil, certo?

Qual a melhor forma de integra estes modulos? Digamos que ao acessar LoginController redirecione para uma pagina com um menu no qual tenha links para estes modulos que não são do mesmo war, e sim separados, será que fui claro, deu para entender Rafael? o que preciso saber LoginController chamar o menu(JSP que esta no mesmo war), após isto como os links desta jsp chamariam os controllers dos outros modulos(wars/ jar externos).

Desde já agradeço.

Entendi Givanildo,

Sua solução teria uma arquitetura mais proxima de microserviços. Em geral a ideia seria decompor uma grande aplicação em outras pequenas, independentes, e que se comuniquem por alguma interface web.

Você poderia fazer com que seus módulos exponham endpoints, uris nos controllers, pra acessar cada ação interna, e os demais módulos, como o de login precisariam conhecê-los, pra chamá-los normalmente. Você poderia até ter um serviço específico pra controlar as uris publicas dos modulos pra facilitar a comunicação.

Existem alguns frameworks que ajudam a gerenciar essa complexidade adicionada neste tipo de arquitetura, assim como automatizar alguns serviços de infraestrutura necessários. Usar Spring Boot para criar os módulos e Spring Cloud é uma solução interessante pra isso (exemplo), assim como Spark, Kumuluz, e outras possíveis soluções.

Dê uma olhada nessas opções podem te ajudar a não gerenciar tudo isso na mão.

Espero ter ajudado. Abraço!

Ok, Rafael , vou dar uma lida, agradeço.

Rafael, mas não teria uma forma mais simples ? Somente fazer por exemplo,um war conversar com outro?

Fala Givanildo, tudo bem ?

Essa arquitetura em geral é mais complexa mesmo. Como se tratam de vários wars, teremos várias aplicações web rodando. Aí a forma mais comum de comunicação entre elas é via requests http. Só que aí os wars terão que conhecer as uris disponíveis nos outros módulos. Esse trabalho que é mais difícil mesmo, você poderia simplesmente manter um padrão de URIs nos módulos, mas aí teria um monte de String fixa na comunicação entre eles, código repetido etc, cada vez que uma URI mudar você precisaria revisar todos os módulos pra atualizar com os novos endereços.

Esse serviço por exemplo é feito pelo framework com o ServiceDiscovery e ServiceRegistration, serviços prontos pra já gerenciar as URIs etc.

Você poderia começar simples, usando alguma lib pra integrar com os outros módulos (RestTemplate já disponível com Spring MVC pode te ajudar) e chamar os controllers dos outros módulos. Mas tem um trabalho aí em saber os endereços de todos os outros módulos.

Boa tarde Rafael, o problema agora, ficou mais simples para você me ajudar, tenho um war no qual quero utilizar uma classe de um jar externo, no caso utilizando injeção de dependencia do Spring, como posso fazer isto, pois estou tentando e está dando erro, veja o tópico que criei "Erro ao injetar com Autowired", será que pode me ajudar? Obrigado.

Fala Givanildo, tudo bem ?

Então. Não vai rolar mesmo essa injeção. Não é possível injetar um bean que está rodando num outro container. A injeção no Spring roda sempre no contexto da DispatcherServlet, e como cada war tem sua própria, ele não da esse suporte. E se formos pensar nessa arquitetura faz sentido mesmo, a ideia é cada serviço ter independência um do outro e não depender de seus recursos internos.

Em geral, nesse tipo de arquitetura um trade off aceitável é a duplicidade de algum código/classe em serviços diferentes, ou uma outra coisa que você poderia pensar é: Se tem dois serviços (wars) dependendo do mesmo recurso, talvez esse recurso necessário poderia ser servido por um outro serviço (war). Aí você planeja a integração entre eles da mesma forma, usando a interface do http e trabalhando do request e response.

Espero ter ajudado. Abraço!

Opa, Rafael, entendi , valeu pela explicação, agradeço mais uma vez.

Opa, por nada ..

A Casa do Código por exemplo trabalha com uma arquitetura desse tipo. E pra evitar ficar com classes iguais em vários módulos, em alguns casos, se usa uma lib com essas classes comuns, e os outros projetos a adicionam como dependência. É uma forma de fugir da repetição, mas sempre quando a lib mudar todos os wars terão que ser atualizados com a nova versão.

São problemas comuns. Dependendo do caso, podemos usar uma das ideias que a gente viu durante a conversa.

Abraço!