Programação orientada a eventos e NoSql - Java

Programação Arquitetura
#1

Oiii gente, não posto muito aqui no guj (tenho medo) as vezes leio tantas brigas rsrs, mas vamos la´.

Estou atuando em um projeto legado, a ideia é atualiza o stack, mas estamos totalmente livres para definir o que faremos. Podemos reconstruir tudo e até mudar a tecnologia.
Atualmente o stack é : Java 6, Struts 1 e algumas coisas com Vraptor, Maven 2, Mochito/Testng, Spring(somente para ID),MySql, Ruby (um módulo do sistema) e hibernarte 3.

O sistema é dividido em vários módulos, mas ainda tem algumas dependências, minha ideia é criar serviços que eliminem essas dependências criando apenas uma ponte entre eles no caso um serviço Rest.

Meu par no projeto sugeriu que refizéssemos todo o sistema usando programação orientada a evento e mudássemos o banco de dados para NoSql.
Quando a programação orientada a evento acho muito interessante em qualquer linguagem, queria saber a experiencia de vocês com esse tipo de abordagem, e quanto ao NoSql eu acho totalmente desnecessário essa migração, o sistema não faz tanta consulta a banco de dados, perder integridade só para usar NoSql não justifica. (Minha leiga opinião, sempre trabalhei co banco de dados relacional)

Estou relutante quanto a ideia do NoSQl e quanto a refazer todo o sistema, tem módulos que sim acho necessário e outros que acredito que refatorar já resolve.

Gostaria da opinião, experiencia e dica de vocês, eu me interesso muito por arquitetura de sistemas mas ainda me sinto muito insegura com algumas decisões e posso estar sendo relutante em algo que talvez seja bom.

Bom, é isso, ficarei grata com a ajuda de vocês.

#2

Oi @Wanessa_Rodrigues.

Infelizmente, no que diz respeito a programação orientada a eventos, tenho pouca experiência, então, não vou opinar. O NoSQL é muito utilizado em sistemas de bigdata, porém, vejo pouco uso em sistemas “comerciais”.

Um ponto que você citou, foi na ideia de criar uma “ponte” de comunicação entre os módulos, usando REST. Na realidade, REST é apenas um modelo de serviço web, então, sua ideia é prover uma API para que seja consumida por outros módulos. Nesse sentido, você pode aplicar DDD, Single Responsability dentro de uma arquitetura de microserviços. A grande pergunta é: vale a pena?

Algo que já vi e presenciei foi querer aplicar conceitos novos simplesmente porque liam em algum lugar ou é “moda”. Na nossa área, fica muito claro que não existem balas de prata e cada caso é um caso. Pela descrição do sistema legado, se migrassem para Java 8, JEE 7 e Wildfly já seria uma baita evolução. Fazer isso tudo usando clean code, TDD e muito bem estruturado, vocês podem dizer que tem um sistema completamente novo. É difícil de opinar sem conhecer o contexto completo, tempo disponível, quantidade de pessoas envolvidas (parece apenas você e outro) e etc. Há inúmeras variáveis que precisam ser analisadas antes de tomar uma decisão de arquitetura.

Minha dica é simples: analisem o contexto do sistema, se ele será ou não disponibilizado em nuvem, nível de performance e segurança exigidos, prazo de entrega entre outros para chegar a conclusão de qual ação tomar. É bom ter cuidado com otimização prematura e acima de tudo, levem a sério o conceito de KISS (Keep it simple, stupid) e cuidado para não usarem uma bala de canhão onde uma bala de .22 resolveria. Espero ter colaborado.

Boa sorte e bom trabalho.

#3

E ae Wan…discussões de alto nível então : )

De tudo o que li sobre seu texto a única parte em que concordo 100 % é quando vc diz

minha ideia é criar serviços que eliminem essas dependências criando apenas uma ponte entre eles

a partir daí não se pode opinar de fora, são questões que possuem N varíaveis e aí fica difícil de te ajudar.

Eu não uso banco relacional há pelo menos 2 anos e confesso que não sinto falta, de fato usar bancos nao relacionais me permite focar no modelo e gravar objetos do jeito que eles foram concebidos (apenas convertendo ele para json ou xml). Sempre tive preconceito com os malditos BO, DTO, TO e no fundo td essa m… servia só para ficar transformando nosso modelo em objetos que faziam sentido pra camada da view, ou pra camada do negócio ou pra salvar num maléfico banco relacional.

Agora existe a questão de q vc não está confortável para migrar para uma base nosql, então não faz sentido vc como membro de um time de duas pessoas entrar nessa. Entretanto saiba que já passou da hora de conhecer alguns, comece com mongodb ou redis são super fáceis.

O projeto em que estou trabalhando atualmente estamos usando o http://firebase.com é quase como não ter banco de dados. E quanto a POE, sei lá, nada demais, nao vejo ganho nenhum com isso.

no mais estamos ae…vamos nos falando bjos

#4

@nel

Gostei da dica do DDD se aplica bem ao caso, estou estudando.

A ideia do Rest é mais para ter aplicações totalmente independentes.

Já vamos migrar para o java 8 e apesar de todos os desafios o TDD foi muito bem aplicado. Estou totalmente de acordo como o conceito KISS, sou a favor da simplicidade e usar somente o necessário.

Obrigado pela resposta!

#5

@Giulliano

Não tenho mais arquiteto para eu encher o saco, preciso recorrer a alguém, vou abusar da consultoria grátis kkkk

A questão não é eu me sentir desconfortável em migrar, na verdade até me anima a ideia, o plano é sair da zona de conforto mesmo. A questão é que eu venho de uma cultura que o banco de dados é o “coração” do seu sistema, não tinha pensado nessa questão dos DTO’s e afins, gostei, realmente abstrai uma camada da aplicação e o uso de um framework orm também (sei que não é obrigatório).

Uma coisas que esqueci de comentar é que um outro sistema “asterisk” usa algumas tabelas desse modelo, ou seja alem de migrar vamos ter que alimentar essas tabelas usadas pelo asterisk, e também geramos alguns relatórios, seria outra base a se alimentada certo ?

Usamos o MySql e estamos estudando a possibilidade de mudar para o Postgreee, levando em consideração que hoje é um modelo relacional seria bem complicado essa migração não ?

Outra coisa, impossível migrar (de forma descente) sem refazer o sistema certo ?

Desculpe dispara tanta pergunta, sei que é difícil opinar sem conhecer, mas se conseguir dar um “pitaco” já me ajuda.

Vou ver esse tal de FireBase ai, aguarde as duvidas kkkk

Obrigado pelas dicas =D

#6

Pelo visto vai ter que refazer toda a cultura de banco de dados pra uma de serviços.

Se fosse apenas refazer o sistema seria fácil.

1 curtida
#7

ah é…e quem disse que é " de grátis :stuck_out_tongue: ". A questão da zona de conforto é muito importante Wan, se vc tem prazo e um sistema legado, então não acho legal comecar a usar conceitos que vc nao conhece ainda, acho que a ideia é estudar sempre a parte.

A parte do ORM normalmente é dispensável assim como esse tal de Struts de 1970. Se vc constrói um sistema baseado em servicos (com RestFul) sua camada de apresentacão pd ser um sistema web, um aplicativo mobile ou qq coisa que fale protocolo HTTP como um arduino por exemplo. Se vc amarra seu sistema ao Struts, então seu sistema só poderá ser um maldito Struts. Diariamente saem novos frameworks MVVM que são infinitamente mais perfomáticos, fáceis e escaláveis do que aplicacões web feitas com frameworks Java

Esse lance do módulo externo usando uma tabela interna ao seu sistema é um erro grosseiro de arquitetura. Se ele está se comunicando diretamente com seu BD (fdeu), senão ainda dá pra mudar sem tanta crise.

Migrar de MySQL para Postgree não entendi o motivo. E não seria complicado ambos são relacionais.

E se vc ainda acredita em regras de negócio espalhadas em td quanto é lugar (na view, no backend e no banco de dados) daí nem vale a pena migrar pra nosql ou restful. Tenho horror a regras no banco de dados, acredito no meu backend que é testado unitariamente e td comunicacão se dá ou passa por ele.

:kissing: