Modularização
08/08/2012 17:51
1
Seguinte eu gostaria de modularizar uma determinada funcionalidade do meu software, exemplo : Tenho um ERP e parte do financeiro seria um módulo.

Como posso fazer isso em Grails ?
Ouvi dizer que dá pra fazer plugins de módulos mas se eu quiser usar em outro lugar aquele módulo apenas tenho que criar outra aplicação instalar o plugin (meio gambi não ?) ?
Como seria o acesso aos domínios pois não seria legal repetir classes em comum para dois módulos, Criar um módulo somente com domínio ?
Como ficaria a segurança caso eu use o Spring Security ?

Ufaaa é isso rs.
Tags: modularização


0
Oi Pedro,

uma boa solução (e nada gambi!) é a criação de plugins para estas funcionalidades. Como você vai organizar a sua estrutura de plugins, ai é outra história.

Hà casos em que você vai querer modularizar apenas as classes de domínio e serviço pra poder criar interfaces customizadas para seus clientes. Em outros você pode até mesmo incluir a interface gráfica junto e modularizar o CSS. Vai depender muito da maneira como sua empresa organiza o seu código.

Outra solução interessante, talvez mais trabalhosa, seja você implementar sua lógica de negócio como arquivos jar separados que você simplesmente importa na sua biblioteca. Já fiz isto uma vez, mas não foi uma boa solução a longo prazo (acabamos percebendo que a modularização foi prévia demais).

Outra alternativa que eu acho muito interessante, mas cujo custo inicial é muito caro é você trabalhar com uma arquitetura OSGi, na qual cada módulo do sistema é um bundle. Mas novamente, é uma opção difícil de trabalhar inicialmente apesar de te oferecer ganhos espetaculares a médio e longo prazo.


0
Este post vai dar uma excelente discussão, razão pela qual o divulguei no Twitter do Grails Brasil. Valeu pelo tópico!


0
Demos inicio á "pluginzacao" de várias coisas que tinhamos, e foi dessa maneira mesmo: faziamos um projeto-plugin e depois instalavamos em quem usava.

Isso foi muito bom, pois nossas classes estavam ficando com responsabilidade bem alta sem muito sentido. Conforme fomos separando as classes diminuimos muito o que estava engessado.

Existe um "Projeto Principal", que tem varios plugins. Os plugins tem Models, e os Models do projeto principal agregam os Models dos plugins.
Exemplo:
tem um plugin que tem o User, que contem as informaçoes do usuario
e o plugin Transactions que tem as informaçoes de transacoes financeiras
no projeto principal tem um model Profile, que contém o User e Transactions

O springsecurity ficou na aplicação principal, por causa dos parametros de configuração.
08/08/2012 18:53


0
Não sei bem se encaixa no tópico, mas uma maneira bem bacana de modularizar sistemas é usando SaaS (software as service).
Estou fazendo esse curso do coursera: https://www.coursera.org/course/saas
E não teve como não mencionar aqui, estou curtindo mto e recomendo =)

Consiste da idéia de disponibilizar sua aplicação como serviço (via get, webservice, etc)

Essa idéia ta crescendo bastante por causa do cloud, da facilidade de escalonar coisas, poder comunicar com aplicações em diferentes linguagens e reutilização.
08/08/2012 19:02


0
Obrigado a todos, Henrique eu falei da "Gambi" rs no sentido de se eu quiser o que é um plugin como aplicação isolada sem a app principal, criar uma aplicação vazia apenas para abrigar este plugin me parece uma Gambi :-).

Mas bem, gostei aí das dicas, e acho que vou rumar para esta estrutura sugerida, eu nunca usei OSGi, ouço falar muito sobre isso, porém tenho medo de iniciar algo que eu não dê conta de concluir e onerar muito tempo do projeto, alguém tem experiência com isso no Grails aqui no fórum? Henrique ? Mussatto ?
08/08/2012 19:22


1
Fui falar de SaaS, acabei falando de SOA hehe

Nunca trabalhei com OSGi =/

Mas a forma de modularizar que eu mencionei era disponibilizando os serviços via webservices soap / rest, e a comunicacao fica toda via xml ou json.

É bem chato pq tem esse trabalho de ficar parseando, mas por sorte o groovy tem uma magavilha chamada XmlSlurper:
http://groovy.codehaus.org/Reading+XML+using+Groovy%27s+XmlSlurper

Uma coisa já adianto, isso dá um trabalho sim, principalmente pra debugar.
Aí tem que ver se vale a pena
08/08/2012 20:06


0
Lembrando que dá pra transformar os objetos em xml com o comando "as XML" tbm
08/08/2012 20:11


0
Sim isso eu já uso muito

'render as XML'
e
'render as JSON'
08/08/2012 20:48


0
sim sim, mas é bom mencionar pra ficar de referencia
tem mta gente que só le, fica com dúvida mas nao posta =)

Algumas praticas que ja vi fazendo eh criar um DTO pra mapear as entradas / saidas dos serviços e umas classes helper pra parsear os DTOs e criar os models
08/08/2012 20:58


1
Só toma cuidado, por que modularizar com o intuito de reutilizar funcionalidades e código costuma ser um doloroso tiro no pé.

Quando você modulariza requisitos não funcionais ou de infraestrutura como ORM, envio de e-mail em massa, conversões, envio de nota fiscal eletronica, etc, é uma coisa que já é complexa. Mas você modularizar requisitos funcionais, que tem regras de negócio específicas de um cliente ou de um sistema, o negócio muda de figura.

Por exemplo, se você fez esse módulo financeiro pra um sistema que atenda uma loja de roupas, dificilmente ele vai ter os mesmos requisitos que um sistema que atenda uma empresa de logística.

Se você desenvolve um produto fechado, e quer fazer uma outra linha de produtos fechado, é mais fácil de fazer, já que você tem controle sobre as funcionalidade. Mas se você presta serviço de desenvolvimento pra várias empresas e quer reaproveitar entre esses vários projetos, simplesmente esqueça essa idéia.

IMHO...
08/08/2012 21:15


0
Não, a ideia é na linha do que o Mussatto falou mesmo, a questão do Financeiro foi apenas um exemplo, outra coisa que pensei é no caso até de distribuição também, poder modularizar para poder distribuir, e para poder re-aproveitar também.
09/08/2012 02:33


0
Mussato,

você possui algum manual mais descritivo sobre "pluginzacao" (Como gerar, manter e distribuir) com boas práticas e mais detalhado? Achei a documentação do Grails muito resumido sobre o tópico.
09/08/2012 14:08


0
Ivgsilva,

Na minha opinião não tem uma prática definida =/
Modularização é uma coisa arquitetural e muda de pessoa pra pessoa, e de projeto pra projeto.

Quando fomos criar plugins no Grails, pensamos como se estivessemos criando bibliotecas do java (só que com varias coisas a mais), que tem que um conjunto de responsabilidades e isoladas. Quanto mais responsabilidade vc define pra uma classe / serviço, mais amarradas as coisas ficam.

Manual eu não sei dizer, mas posso apontar dois livros muito bons pra esse assunto: Clean Code e Pragmatic Programmer.
O Clean Code eu considero leitura obrigatoria =)
09/08/2012 14:18


0
O maven foi fundamental pra criar os plugins.
A automatizacao dos testes e controle de versão foram um divisor de aguas.

Não lembro bem porque mas o Ivy deu muita dor de cabeça por não trocar as versões do plugin direito.
09/08/2012 14:26


1
Seguimos esse tutorial: http://www.znetdevelopment.com/blogs/2012/07/15/grails-2-1-and-maven-integration-multi-module-projects/
Pra criar a estrutura do projeto.

Tem uma coisa que deu dor de cabeça aqui: quando vc cria um plugin (grails create-plugin), ele não vem por padrão com o plugin do hibernate pra usar direito os models

Desculpas por "em partes", é que fui lembrando das coisas.
09/08/2012 14:38


0
Mussatto,

valeu pela dica e pelo tutorial. E o que vc fez para corrigir a falha da ausência do plugin hibernate (no grails create-plugin), instalou outro plugin complementar?

09/08/2012 14:59


0
só mandei instalar o plugin do hibernate mesmo (e coloquei no pom.xml)
09/08/2012 15:05



Ainda não faz parte da comunidade???

Para se registrar, clique aqui.


Aprenda Groovy e Grails com a Formação itexto!

Newsletter Semana Groovy

Assinar

Envie seu link!


Livro de Grails


/dev/All

Os melhores blogs de TI (e em português) em um único lugar!

 
Creative Commons
RSS Grails Brasil é mantido por itexto Consultoria.
Em caso de problemas contacte Henrique Lobo Weissmann (Kico) por e-mail: kico@itexto.com.br
Todo o conteúdo presente neste site adota o Creative Commons como licença padrão.
Ver: 4.14.0
itexto